Re: Comments on recursive merge..

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 11, 2005, 22:53 UTC
Message-ID: <Pine.LNX.4.64.0511111437410.3228@g5.osdl.org>
In-Reply-To: <7v4q6ilt3m.fsf@assigned-by-dhcp.cox.net>

On Fri, 11 Nov 2005, Junio C Hamano wrote:

Show 5 quoted lines

> 
> Some observations.
> 
>  - Trivial Merges count is surprisingly high.  About 1/3 of
>    merges are pure in-index merges.

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.

>  - Most of the commits (developer commits, not merges) are
>    small and touches only a couple of paths.

This is something where I think the kernel is perhaps unusual, especially for a big project. We really do encourage people to make lots of small and well-defined changes, and the whole flow of development has been geared towards it.

>  - Nobody does octopus ;-).

I do think octopus is really cool, and still think seeing that five-way octopus-merge in gitk in the git history was really really cool.

It doesn't look as good any more, btw: do "gitk" on the current git tree, and search for "Octopus merge", and you'll see some of the history lines crossing each other. Paul?

But yeah, it's a pretty special thing. I think its coolness factor way outweighs its usefullness factor ;^p

>  - We did not have multi-base merge case during the period
>    looked at (but the sample count is very low).

Again, this is possibly because the kernel has already had a few years of distributed SCM usage under its belt, and we've tried to not only merge in a timely manner, but also try to keep history reasonably clean and not have a lot of cross-merging back and forth. That cuts down on multi-base possibilities.

Show 7 quoted lines

>  - merge-one-file was called for only a handful (median 8)
>    files, which is negligibly small compared to the total 17K
>    files in the kernel tree, and fairly small compared to the
>    number of changed paths from the first parent (meaning,
>    read-tree trivial collapsing helped majorly).  Among them,
>    the number of paths that needed real file-level 3-way merges
>    were even smaller (avg 1.96).

I definitely think this is true for any big project.

Small projects will inevitably have changes that modify large portions of the source base. But with small projects, it doesn't really matter _what_ you do, you can do it fast.

Big projects (at least the sane kind) will never have lots of changes that modify a very big percentage of the source-tree. It's just too painful (and I'm not talking from a SCM angle, just from a developer angle).

>    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. Sure, it's a good sign that my mental model of what the usage patters are does actually match reality, but at the same time it might be more interesting to see if other projects that use git end up using it the same way and/or have different statistics.

I do expect that the size of the project will impact the statistics a lot.

		Linus