Re: git merge and merge message

[Avi Kivity <avi@qumranet.com>]

Linus Torvalds wrote:
> On Sun, 11 Mar 2007, Avi Kivity wrote:
>   
>> Actually there's at least one tree where this should be activated -- yours.
>> If you perform a fast-forward merge, there's no record of the merge, no record
>> of which tree was pulled, and no sign-off from you.  The commits just appear
>> there.  It partially defeats the sign-off system.
>>     
>
> Well, the thing is, I explicitly don't *want* the merges to show up if 
> it's a fast-forward. 
>
> Maybe it's just me, and maybe I'm odd, but I have for several years now 
> really thought of Linux development as being this collection of 
> maintainers, rather than being a "Linus at the top" kind of situation. 
>   

Maybe you are a little odd, but I don't think that it's just you.  It's 
quite clear that there are some areas where you don't generally involve 
yourself, and others where you do.

> So yes, obviously I do end up getting a lot of merges attributed to me, 
> simply because *in practice* my tree is generally the top of the food 
> chain, but I think that's a practical issue because people generally want 
> to avoid confusion by having a known maintainer, and it shouldn't be a 
> design thing.
>   

As it is, whether a merge is recorded or is practically random: if two 
perfectly rebased pull requests come in, one will just appear magically 
in the tree and the other will have a merge record.

You could make most pulls have no merge record by rebasing them, but 
that would cause confusion since commits would just appear and it would 
be impossible to trace them based on the contents of one's tree alone.

I agree it shouldn't be a design thing: I think that on the lower level 
of the "tree of trees", people should avoid merge records since they are 
just noise (and indeed most/all maintainers present perfectly groomed 
trees which have no relation to how development actually happened), but 
on the top levels, we need the traceability.  We need the record of a 
decision that was made to pull from X's tree at date Y.


> So I dislike the "hierarchical model" so much that even though it's true, 
> I don't want to make it even _more_ true. I'd rather make it less true, 
> and at least personally think of Linux development more as a "network of 
> developers where some people are just more connected than others". I'm not 
> saying that people are equal (because they aren't), but at the same time I 
> do think that it should be perfectly fine if submaintainers pull from each 
> other if they ever need to - ie pulling should work side-ways and not just 
> up the "command chain".
>   

-mm and a few other trees approximate that model.  These types of trees 
mostly use quilt, though, which allows an "editable history" mode of 
operation.

As a maintainer, I would be very wary of pulling sideways.  There's the 
risk of the final upstream being very different from what one pulls, and 
therefore one is left with a pile of conflicts to fix.  There's the risk 
of the other tree not being pulled at all, blocking one's own work.  I 
don't even want to think about a "no single upstream" mode, that would 
confuse users in addition to developers.

> So I think the hierarchical thing is largely a social thing, but not one 
> that is necessarily the only way of doing things. 
>
> And I believe that it might actually be *better* if we were to have some 
> more merging side-ways. Yes, I've been rather involved in kernel 
> development for fifteen years, and I don't really see myself stopping it 
> either, but at the same time, I think that in the really long run, it 
> would be a really interesting experiment to try to run things as a more 
> "amorphous" development group of people that just trust each other, than a 
> very hierarchical one.
>   

The hierarchical model does have advantages: you can always get a 
decision (it may be the wrong one, but it's better than no decision), 
and more important, it's clear and understandable.

> I realize that it can be useful, and I obviously use the "merge.summary" 
> config variable that does make it a non-symmetric situation anyway, and 
> maybe I'm just fighting windmills. It's just that I actually dislike the 
> central repository model so much that I dislike it even when the central 
> repository is *me*.
>
>   

Maybe you would like it more if the central repository wasn't you :) - 
it really provides a reference frame against which to work, even if it 
is moving all the time.  It reduces the risks of working on something 
that is going away.

-- 
error compiling committee.c: too many arguments to function