I was hoping that it was just a form of `git merge -s ours` but, you're right, the manpage makes it look a lot scarier.
I read the linked blog post and I still don't see a good use case for git replace. I can think up a lot of potential downsides and sources of mass confusion of course!
So, I second that. Anyone know a good, real-world, use for git replace? The example given in the blog post seems overcomplex. It would be easier and more idiomatic to just use rebase. (Yes, rebasing would change the commit SHAs, but would anybody care?)
You could in principal store the old history in a separate repository then (reasons for this may be that the repo historically contained many binary files, possibly because it’s been converted from an SVN repo). After refactoring and rebasing (Note: You do in fact change the SHAs in this scenario – what they do in the blog post is a rebase+squash/fixup basically.) you prepare a new repo which is much smaller and in which you do all further development.
However, sometimes it may be necessary for developers to do a `git blame` which needs to include the old data or similar. If this happens, you add the historical repo as another remote and `git replace` the oldest commit from the dev repo with the historical repo.
Only a few developers will ever need to use `git replace` in this scenario, so it would not say that it is too confusing. (If it was confusing, I’d say everybody would probably have learned that it exists the hard way…) Maybe think of it as a kind of git submodule but for time.
Sometimes using git replace followed by git filter-branch (so that you wind up with a valid history with all hashes correct) is the best way to get the history you want. This is usually in really extreme cases. ie at Loggly we had a frontend repo that we wound up splitting into media, templates, and webapp repos, and then later decided to put back into a frontend repo. The former operation was pretty easy with filter-branch, but for the latter, I used replace + filter-branch.
I read the linked blog post and I still don't see a good use case for git replace. I can think up a lot of potential downsides and sources of mass confusion of course!
So, I second that. Anyone know a good, real-world, use for git replace? The example given in the blog post seems overcomplex. It would be easier and more idiomatic to just use rebase. (Yes, rebasing would change the commit SHAs, but would anybody care?)