Re: [O] Contributing Without Patches ...

[Suvayu Ali]

On Sat, Sep 14, 2013 at 10:09:42PM +0200, Achim Gratz wrote:
> Suvayu Ali writes:

(I took the liberty to re-order the quoting below to clarify my argument.)
 
> > 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.
>
> > 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.

But isn't this the whole point: Linus pulls from subsystem maintainers,
they pull from the group of people they work with; an expanding circle
of trust?  So in the end no one ends up with hundreds of remotes.

> > 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 think you are overlooking that I make a distinction between author and
committer.  But probably I'm being unnecessarily pedantic; after all
that's why git format-patch has --signoff.

> > 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.

In the context of the OP's contributions, you are right.  His patches
are just patches.  My comment to Eric's message was more general, but I
admit I wasn't clear in my response.

> > 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.

Me too.

> > 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.

I guess here the social context of the software project matters.  In my
most common use case (software implementing physics analysis), I find
historical information (e.g. design decisions, physics choices, updated
findings, correctness compromises, ...) are equally important to code
clarity.  So if I can keep historical information, I do.  Sometimes I
simplify history when it is too messy, but document it in commit
messages.

(A very OT comment) I came across a few discussions on the Git mailing
list where a user wanted to document historical information of a
(non-software) project as a Git repository!  The particular case I have
in mind was to document legal history.  What I intend to illustrate with
this is: Git history is an amazingly versatile repository of
information.  Sometimes it is not obvious exactly what it holds.  So I
go by "keep the info unless you are sure there is no need".

Anyway, we have deviated from Org mode way too much.  I will shut up
now, I mean it this time :-p.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.