Re: clone breaks replace
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Jan 11, 2011, 19:48 UTC
- Message-ID
- <201101112048.57326.j6t@kdbg.org>
- In-Reply-To
- <20110111173922.GB1833@sigill.intra.peff.net>
On Dienstag, 11. Januar 2011, Jeff King wrote:
Show 8 quoted lines
> 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.
Show 13 quoted lines
> 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