Hi, Thoughts on use cases. Jeff already explained the main protocol problem to be solved very well (thanks!). Phillip Susi wrote: > 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. This does not require transport respecting replacements. Just start a new line of history and teach "git pull" to pull replacement refs first when requested in the refspec. It could work like this: alice$ git branch historical alice$ git checkout --orphan newline alice$ git branch newroot alice$ ... hack hack hack ... alice$ git replace newroot historical alice$ git push world refs/replace/* +HEAD:master bob$ git remote show origin URL: git://git.alice.example.com/project.git Ref specifier: refs/replace/*:refs/replace/* refs/heads/*:refs/remotes/origin/* HEAD branch: master Remote branch: master tracked Local branch configured for 'git pull': master merges with remote master bob$ git pull remote: Counting objects: 18, done. remote: Compressing objects: 100% (11/11), done. remote: Total 11 (delta 8), reused 0 (delta 0) Unpacking objects: 100% (11/11), done. From git://git.alice.example.com/project.git * [new replacement] 87a8c7yc65c87c98c87c6a87c8a -> replace/87a8c7yc65c87c98c87c6a87c8a a78c9df..8c98df9 master -> origin/master > 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. With the method you are suggesting, others do _not_ always have the original still available. After I fetch from you with --respect-hard-replacements, then while I am on an airplane I will have this hard replacement ref staring at me that I cannot remove. If the original goes missing or gets corrupted on the few machines that had it, the hard replacement ref is permanent. > 3) Inserting a replace record takes a lot less cpu and IO than > filter-branch rewriting the entire chain. If the modified history is much shorter than the original (as in the use case you described), would building it really take so much CPU and I/O? Moreover, is the extra CPU time to keep checking all the replacements on the client side worth saving that one-time CPU time expenditure on the server? If (and only if) so then I see how that could be an advantage. Sorry for the longwinded message. Hope that helps, Jonathan -- 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