Re: Subtree in Git

[Junio C Hamano <gitster@pobox.com>]

<dag@cray.com> writes:

> 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.