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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html