On 1/11/2011 1:52 AM, Jonathan Nieder wrote: > I have two worries: > > - first, how easily can the replacement be undone? (as you mention > below) git replace -d id, or git --no-replace-objects. It also might be nice to add a new switch to git replace to disable a replace without deleting it, so that it can later be enabled again. > - second, what happens if the two ends of transport have different > replacements? Then you have a conflict, just like if the two ends have different tags with the same name. > That second worry is the more major in my opinion. Shallow clones are > a different story --- they do not fundamentally change the history and > they have special support in git protocol. It is possible to punt on > both by saying that (1) replacements _cannot_ be undone --- a second > replacement is needed --- and (2) the receiving end of a connection is > not allowed to have any replacements for objects in common that the > sending end does not have, but then does that buy you anything > significant over a filter-branch? One of the major advantages of replacements is that they can easily be undone, so defeating that would be silly. Just like with conflicting tags, if the receiving end has conflicting replacements, they will be kept instead of the remote version and a warning issued. If you want the remote version, delete your local one and fetch again. What it buys you over filter-branch is: 1) Those tracking your repo don't have breakage when they next fetch because the chain of commits they were tracking has been destroyed and replaced by a completely different one. 2) It is obvious when a replace has been done, and the original is still available. This is good for auditing and traceability. Paper trails are good. 3) Inserting a replace record takes a lot less cpu and IO than filter-branch rewriting the entire chain. -- 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