On 1/11/2011 3:00 PM, Johannes Sixt wrote: > On Dienstag, 11. Januar 2011, Jeff King wrote: >> I think you missed the first part of this discussion. Phillip is >> proposing that it should, and I am arguing against it. > > You're right, sorry for the noise. Now I understand this three-word-subject. What it really comes down to is that you can use replace locally to modify your history and it works great. As soon as someone clones from you though, they don't get the replace and so they end up with a different history than you see. I suggested that git-upload-pack should respect replace records by default, so that people cloning your repository will get the same replaced history instead of the original. It seems that the recommended use of replace is to locally append history back on, after it has been removed upstream with git filter-branch. Using filter-branch is bad, so it makes more sense to me to do the remove with git replace, and then if you want to add it back, you just have to disable the replace ( and maybe fetch additional objects ). The one problem that has come up is that when you fetch and tell the server you have a commit after the replace, it assumes that you also have the commits prior to the replace and may delta against objects you do not have. Fixing that would require informing the server of any replacements you have, and it being able to use that information to avoid deltas against objects hidden by the replace. Does that sound like a pretty good summary to everyone? -- 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