Thread (1 message) 1 message, 1 author, 2016-06-15

Re: git-subtree Ready #2

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:06

Junio C Hamano [off-list ref] writes:
greened@obbligato.org (David A. Greene) writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help