Re: Subtree in Git

[off-list ref] writes:

Herman van Rink [off-list ref] writes:

quoted

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.