<dag@xxxxxxxx> writes: > Herman van Rink <rink@xxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html