Re: clone breaks replace

From: Jeff King <peff@peff.net>
Date: Jan 7, 2011, 22:09 UTC
Message-ID: <20110107220942.GB10343@sigill.intra.peff.net>
In-Reply-To: <20110107214907.GA9194@burratino>

On Fri, Jan 07, 2011 at 03:49:07PM -0600, Jonathan Nieder wrote:

Show 13 quoted lines

> Phillip Susi wrote:
> 
> > Take the kernel history as an example, only imagine that Linus did not
> > originally make that first commit leaving out the prior history, but
> > wants to go back and fix it now.  He can do it with a replace, but then
> > if he runs filter-branch as you suggest to make the change 'real', then
> > everyone tracking his tree will fail the next time they try to pull.
> > You could get the same result without replace, so why bother?
> >
> > If the replace was fetched by default, the people already tracking would
> > get it the next time they pull and would not have a problem.
> 
> Interesting.  I hadn't thought about this detail before.

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.

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].

Which leads to the second question. It is basically a matter of saying "do you want to fetch the view that upstream has"? I can definitely see that being useful, and meriting an option. However, it may or may not be worth turning on by default, as upstream's view may be confusing.

-Peff

[1] Actually, what we are talking about it basically shallow clone.
    Which does do exactly this truncation, but does not use the replace
    mechanism. So it _is_ possible, but lots of things need to be
    tweaked to understand the shallow-ness. Perhaps in the long run
    making git understand replacement-truncated repos with missing
    objects would be a good thing, and shallow clones can be implemented
    simply as a special case of that. It would probably make the code a
    bit cleaner.