On Tue, Jul 6, 2010 at 2:00 PM, Eric Niebler <eric@xxxxxxxxxxxx> wrote: > On 7/6/2010 1:27 PM, Avery Pennarun wrote: >> The primary advantage of grafts is that you can do something easy >> *right now* and then fix it all up later. eg. if you screw up your >> history extraction and do it better later, you can just re-graft it >> and you're done. > > How does one screw up the history extraction, if one is not doing any > fancy history rewriting (in this scenario)? Be there dragons? Well, "rewriting history" necessarily involves changing things about the permanent record. Every time you change things, you have a potential to change them incorrectly. So in general, not rewriting is less error-prone than rewriting :) Specifically, with a tool like git-subtree, it only really works if a particular subproject has always existed in the same subdir of your repo since it started. If the subdir was ever renamed, or if some of the files were previously part of one subdir but then moved around, git-subtree doesn't (currently) know how to deal with that. git-filter-branch can do anything you want, but you have to teach it how, which is obviously even *more* error prone. Things are also a little messy if you have some kind of top-level directory with build infrastructure shared by all the subdirs. Does the top-level Makefile have a list of the subdirs it needs to build? If so, there's no way to extract only a subset of true history that will still build correctly - it'll be looking for directories that you explicitly removed. You could update the Makefiles programmatically in every single revision, but that's starting to get extremely messy... and your history stops representing what *real life* really looked like at the time. If your subdirs haven't been moving around (which sounds like that might be the case for you), and you don't have any top-level files that you care about, rewriting might turn out to be straightforward. You could also make the decision on a subdir-by-subdir basis, I guess. Have fun, Avery -- 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