Re: clone breaks replace

From: Phillip Susi <psusi@cfl.rr.com>
Date: Jan 11, 2011, 18:42 UTC
Message-ID: <4D2CA4AC.8060005@cfl.rr.com>
In-Reply-To: <20110111182225.GE15133@burratino>

On 1/11/2011 1:22 PM, Jonathan Nieder wrote:

Show 7 quoted lines

>> 1)  Those tracking your repo don't have breakage when they next fetch
>> because the chain of commits they were tracking has been destroyed and
>> replaced by a completely different one.
> 
> This does not require transport respecting replacements.  Just start
> a new line of history and teach "git pull" to pull replacement refs
> first when requested in the refspec.

That's what I've been saying. My statement that you quote above is stating why git replace is better than git filter-branch.

Show 8 quoted lines

>> 2)  It is obvious when a replace has been done, and the original is
>> still available.  This is good for auditing and traceability.  Paper
>> trails are good.
> 
> With the method you are suggesting, others do _not_ always have the
> original still available.  After I fetch from you with
> --respect-hard-replacements, then while I am on an airplane I will
> have this hard replacement ref staring at me that I cannot remove.

They may not have it in their local repository, but it is clear that there IS an original history, and the replace record comment should tell them from where they can fetch it, and those tracking the repository before the replace was added already have it.

Using filter-branch on the other hand, is a sort of dirty hack that violates the integrity constrains normally in place, and can leave you with a history that has no indication that there ever was more.

> If the original goes missing or gets corrupted on the few machines
> that had it, the hard replacement ref is permanent.

I think it goes without saying that if you loose part of the repository, and there are no other copies, then you have lost part of the repository.

Show 5 quoted lines

> If the modified history is much shorter than the original (as in the
> use case you described), would building it really take so much CPU and
> I/O?  Moreover, is the extra CPU time to keep checking all the
> replacements on the client side worth saving that one-time CPU time
> expenditure on the server?

It would take more than just inserting the replace record. I'm not sure what you mean by "keep checking all the replacements on the client side".