Re: Subtree in Git

From: Junio C Hamano <gitster@pobox.com>
Date: May 11, 2012, 20:24 UTC
Message-ID: <7vaa1elb4t.fsf@alter.siamese.dyndns.org>
In-Reply-To: <nngzk9jvemb.fsf@transit.us.cray.com>

<dag@cray.com> writes:

Show 8 quoted lines

> Herman van Rink <rink@initfour.nl> writes:
>
>> As an alternative I've now applied a patch with all changes on a clean
>> master branch.
>> In the commit message I've named all committers from the original history.
>> Would that be acceptable?
>
> Seems ok to me but Junio has the final say.

What we do *not* want to see are merges from commits after the "subtree" stuff is moved down to "contrib/subtree" into commits before the merge happened, as that would mean "constant renaming merge" mess in the history (see http://article.gmane.org/gmane.comp.version-control.git/197689 as well).

If it is too much trouble to clean up the history, it is OK to leave "oops, an earlier one was a total mistake but it is too late to rewind the tree, so here is a fixup" commits. At the very least, however, it should be possible to clean up the history to pretend that everything has happened _after_ the "git-subtree" project transitioned to have its files under "contrib/subtree" hierarchy in preparation for eventually becoming a part of the core git, no? Then the back-merges from your tree to Herman's will be merging updates to contrib/subtree part into contrib/subtree part, and "git log contrib/subtree" will give us a readable output.

I thought "subtree" was a tool to make it very easy to let you pretend that everything happened in the context of containing larger tree when you wanted to, so I am hoping that is not asking too much (even a subtree unaware "filter-branch" should be able to do that kind of thing, I would think).

Thanks.