Re: clone breaks replace

[Phillip Susi <psusi@cfl.rr.com>]

On 1/11/2011 1:52 AM, Jonathan Nieder wrote:
> I have two worries:
> 
>  - first, how easily can the replacement be undone? (as you mention
>    below)

git replace -d id, or git --no-replace-objects.  It also might be nice
to add a new switch to git replace to disable a replace without deleting
it, so that it can later be enabled again.

>  - second, what happens if the two ends of transport have different
>    replacements?

Then you have a conflict, just like if the two ends have different tags
with the same name.

> That second worry is the more major in my opinion.  Shallow clones are
> a different story --- they do not fundamentally change the history and
> they have special support in git protocol.  It is possible to punt on
> both by saying that (1) replacements _cannot_ be undone --- a second
> replacement is needed --- and (2) the receiving end of a connection is
> not allowed to have any replacements for objects in common that the
> sending end does not have, but then does that buy you anything
> significant over a filter-branch?

One of the major advantages of replacements is that they can easily be
undone, so defeating that would be silly.  Just like with conflicting
tags, if the receiving end has conflicting replacements, they will be
kept instead of the remote version and a warning issued.  If you want
the remote version, delete your local one and fetch again.

What it buys you over filter-branch is:

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.

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.

3)  Inserting a replace record takes a lot less cpu and IO than
filter-branch rewriting the entire chain.