Re: git-subtree Ready #2

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 21, 2012, 08:44 UTC
Message-ID: <7v4nukinio.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vwr7gitjl.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> greened@obbligato.org (David A. Greene) writes:
>
>> Ok, but we will preserve the history via the subtree merge, yes?
>
> I'll comment on just this part, but a short answer is "no, I do not think
> so".
> ...
> I was saying that the history up to the current state, littered with these
> commits that are not "logical progression" but merely "a snapshot of
> then-current state" may not be worth preserving, with or without better
> messages.
>
> Rewriting the entire history to make it a logical progression just for the
> sake of history is obviously not worth the effort.

Having said all that, my preference is not so strong to out-right veto doing a true merge; I wouldn't lose sleep if we end up merging the tip of your subtree branch with all the history behind it as-is.

BUT.

Even though I freely admit that I was the guilty one who came up with "merge -s subtree", and Linus's "gitk merge" was the original sin, having a subtree merge like gitk, git-gui and gitweb in the history is not without downsides.

The most problematic one that we regularly suffer from is that the commands in the log family cannot work well across a subtree merge with pathspec limiting, e.g. "git log git-gui/po", and we have to resort to something like:

    $ cd git-gui/po &&
      git rev-list --parents HEAD . |
      while read commit parent
      do
        git log --pretty=short $parent..$commit^2 -- :/po
      done | git shortlog -n -e

to achieve what should be a simple "git shortlog -n -e git-gui/po". I suspect that a subtree merge may also lead bisection into uninteresting tangents as it joins otherwise disjoint history.

If we still have an active upstream that grows its history in a separate repository, like gitk and git-gui do, we cannot avoid a subtree merge in order to continue merging from them. Because you seem to be taking over and are going to maintain it as part of git.git proper, eventually aiming to move it out of contrib/, it's just that I do not think it is worth the trouble.