From: Phillip Susi <psusi@cfl.rr.com>
Date: Tue, 11 Jan 2011 15:24:01 GMT
Subject: Re: clone breaks replace
Message-ID: <4D2C7611.6060204@cfl.rr.com>
In-Reply-To: <20110111054735.GC10094@sigill.intra.peff.net>

On 1/11/2011 12:47 AM, Jeff King wrote:
> Once you have fetched with that view, how locked into that view are you?
> Certainly you can never push to or be the fetch remote for another
> repository that does not want to respect that view, because you simply
> don't have the objects to complete the history for them.

If you want to fetch the original history, then it is as simple as git
--no-replace-objects fetch.  Unless of course, the upstream repository
actually removed the original history ( or you are pulling from someone
else who only pulled the truncated history ), possibly transplanting it
to a historical repository that they should refer you to in the message
of the replace commit.  Then you just fetch from there instead, and
viola!  You have the complete original history.

> I guess you can get the parent pointer from the real, "non-replaced"
> object and ask for it. But you can't ask for a specific commit, so for
> every such truncation, the parent needs to publish an extra ref (but
> _not_ make it one of the ones fetched by default, or it would nullify
> your original shallow fetch), and we need to contact them and find that
> ref.

Yes, either a new branch or separate historical repository could be
published to pull the original history from, or git would need to pass
the --no-replace-objects flag to git-upload-pack on the server, causing
it to ignore the replace and send the original history.