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. 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. Now you want to fetch from another server S2, which built some commits on the original history: A--B--C--D--E--F You and S2 negotiate that you both have D, which implies that you have all of the ancestors of D. S2 therefore sends you a thin pack containing E and F, which may contain deltas against objects found in D or its ancestors. Some of which may be only in A, which means you do not have them. Aside from fetching the entire real history, the only solution is that you somehow have to communicate to S2 exactly which objects you have, presumably by telling them which replacements you have used to arrive at the object set you have. Which in the general case would mean actually shipping them your replacement refs and objects (simply handling the special case of commit truncation isn't sufficient; you could have replaced any object with any other one). -Peff -- 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