Re: Contributing Without Patches ...

[Achim Gratz <Stromeko@nexgo.de>]

Suvayu Ali writes:
> Isn't that two commands away:
>
> $ git remote add <name> <some_url>
> $ git pull <name> <branch>

… and if you are a maintainer, then you'll have hundresds of remotes in
no time.

> If you use patches, you do lose committer information.

You might want to check that assumption.  You can do it in many ways,
but by default you don't lose information: the author, the time of
change and the complete commit message is kept.

> I hear this advise often: rebase before adding features.

Features are not patches and the other way around.  I've been working
with feature branches as well as rebased features before pushing them
out.  It depends a lot on what you want to achieve and who you are
working with.  There is no single right choice here.

> But isn't that trying to work in the old ways of linear history.

There is nothing inherently wrong with linear history.  I tend to
rewrite a lot of history when it helps to make the intention of the code
more clear.

> If there is a need (when working on large features), then there is no
> harm in using separate branches and merging from time to time.  If Git
> allows you to, why not take advantage of it.  After all that is one of
> the strongest points about Git, it's branching and merging abilities.
> I often find a lot of useful information (about design decisions,
> choices) hidden in the history.

If that is important to you, by all means do it.  But often I think it's
more important to present the code changes in a more coherent fashion
than to stress the fact that I thought of some base functionality only
after I've dithered about on some accidental detail.  In particular if
I'm going to send a patch series to a maintainer, I would rather want
him to understand the code to decide if the patch is good or needs more
work.  Publishing code is like publishing text: sometimes the notes are
interesting and important, but most often they are not.

> Not solely.  It depends on the developer.  Here are two random examples
> from a Google search of "lkml pull request".

These are subsystem maintainers which all have their own public branches
for their staging repositories.  That is exactly the thing that pull was
meant for.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada