Re: Comments on recursive merge..

From: Junio C Hamano <junkio@cox.net>
Date: Nov 12, 2005, 00:42 UTC
Message-ID: <7v8xvuk876.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0511111437410.3228@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 7 quoted lines

> I actually don't think that is surprisingly high, and would actually have 
> expected it to be closer to 50%.
>
> On the other hand, the merges that end up being pure fast-forwards aren't 
> counted as merges at all (since they don't show up as commits), so maybe 
> that's what skews my preception of a big percentage of merges as being 
> really trivial.

That is what I meant by "it does not show just what you saw". It shows the whole community experience by everybody who has commit there. Being _the_ integration point, I imagine that most of the pure fast-forwards you saw were real merges for somebody else, and that merge being fast/safe/convenient counts, not for you but for your subsystem people.

Show 6 quoted lines

>>    All three of these points together is a fine demonstration
>>    that you designed git really right.
>
> Well, it's self-re-inforcing. It was designed for the kernel
> usage patterns, so using the kernel to confirm that it's the
> "right design" is a bit self-serving.

That is true. My point was that it's not like git was done right only for _you_, sacrificing subsystem people. The sample 4k commits show that the assumption of the usage pattern git is optimized for actually holds (commits being small, merges being mostly trivial) for kernel people other than you.

It is yet to be seen if the same assumption holds for other projects.