Phillip Susi wrote: > 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? Yes, except for "Using filter-branch is bad". Using filter-branch is not bad. Also there are many recommended uses of replace: for example, to swap out a commit that builds for one that doesn't when using "git bisect", or to stage history changes before making them permanent with filter-branch. -- 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