Phillip Susi wrote: > Take the kernel history as an example, only imagine that Linus did not > originally make that first commit leaving out the prior history, but > wants to go back and fix it now. He can do it with a replace, but then > if he runs filter-branch as you suggest to make the change 'real', then > everyone tracking his tree will fail the next time they try to pull. > You could get the same result without replace, so why bother? > > If the replace was fetched by default, the people already tracking would > get it the next time they pull and would not have a problem. Interesting. I hadn't thought about this detail before. > Those cloning the repository for the first > time would get it, and avoid fetching all of the old history since they > would be using the replace record in place of the original commit. No, it doesn't work that way. Imagine for a moment that each commit object actually contains all of its ancestors. That isn't precisely right but in a way it is close. To change the ancestry of a commit, you really do need to change its name. If you disagree, feel free to try it and I'd be glad to help where I can with the coding if the design is sane. Deal? Maybe it would be nice if git replace worked that way, but that would be fundamentally a _different_ feature. -- 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