On 1/7/2011 4:49 PM, Jonathan Nieder wrote: > 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? That's why a replace record seems to be the perfect solution. The original record still references the old history, but you ignore it in favor of the replacement, which does not. Thus you have a choice; you ignore the replacement and use the original with the full history attached, or you respect the replacement and the history is truncated. As long as git-upload-pack respects the replacement, then new checkouts will ignore the old history. You could then create a new historical branch that points to the parent commit of the replaced one, and tell people to fetch that branch to get the old history, or pass --no-replace-objects over the wire to git-upload-pack. -- 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