Re: clone breaks replace

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

On 01/07/2011 05:09 PM, Jeff King wrote:
> I think there are two separate issues here:
>
>    1. Should transport protocols respect replacements (i.e., if you
>       truncate history with a replacement object and I fetch from you,
>       should you get the full history or the truncated one)?
>
>    2. Should clone fetch refs from refs/replace (either by default, or
>       with an option)?
>
> Based on previous discussions, I think the answer to the first is no.
> The resulting repo violates a fundamental assumption of git. Yes,
> because of the replacement object, many things will still work. But many
> parts of git intentionally do not respect replacement, and they will be
> broken.

What parts do not respect replacement?  More importantly, what parts 
will be broken?  The man page seems to indicate that about the only 
thing that does not by default is reachability testing, which to me 
means fsck and prune.  It seems to be the purpose of replace to 
/prevent/ breakage and be respected by default, unless doing so would 
cause harm, which is why fsck and prune do not.

> Instead, I think of replacements as a specific view into history, not a
> fundamental history-changing operation itself. Which means you can never
> save bandwidth or space by truncating history with replacements. You can
> only give somebody the full history, and share with them your view. If
> you want to truncate, you must rewrite history[1].

Right, but if you only care about that view, then there is no need to 
waste bandwidth fetching the original one.  It goes without saying that 
people pulling from the repository mainly care about the view upstream 
chooses to publish.  Upstream can choose to rewrite, which will cause 
breakage and is a sort of sneaky way to hide the original history, or 
they can use replace, which avoids the breakage and gives the client the 
choice of which view to use.