Re: clone breaks replace

[Johannes Sixt <j6t@kdbg.org>]

On Dienstag, 11. Januar 2011, Jeff King wrote:
> On Tue, Jan 11, 2011 at 10:24:01AM -0500, Phillip Susi wrote:
> > 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.
>
> AFAIK, git can't pass --no-replace-objects to the server over git:// (or
> smart http). You would need a protocol extension.

Why would you have to? git-upload-pack never looks at replacement objects.

> And here's another corner case I thought of:
>
> Suppose you have some server S1 with this history:
>
>   A--B--C--D
>
> and a replace object truncating history to look like:
>
>   B'--C--D
>
> You clone from S1 and have only commits B', C, and D (or maybe even B,
> depending on the implementation). But definitely not A, nor its
> associated tree and blobs.

Why so? Cloning transfers the database using git-upload-pack, 
git-pack-objects, git-index-pack, and git-unpack-objects. All of them have 
object replacements disabled. (And AFAICS, there is no possibility to 
*enable* it.)

Therefore, after cloning you get

 A--B--C--D

and perhaps also the replacement object B'.

Hint: git grep read_replace_refs

-- Hannes