Subject: Re: clone breaks replace

From: Phillip Susi <[email-masked]>
Date: Fri, 07 Jan 2011 17:09:33 -0500

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.