Are there any downsides to enabling git rerere?

I’ve read various things about git‘s rerere feature, and I’m considering enabling it. But I haven’t seen anyone mention any possible problems that could arise while using it. I have to assume there is a downside, or it would probably be enabled by default. So is there any downside to enabling rerere? What potential problems can it cause that would not otherwise occur?

  • How to search changes with `git log` and show the matching lines?
  • .gitignore being ignored by Visual Studio?
  • how to clone an old git-commit (and some more questions about git)
  • GitKraken config file
  • git flow branch dependencies
  • Git and Capistrano: Authentication failed for Visual Studio Team Foundation Server 2013 (TFS)
  • How do I refer to the last commit in a branch with git?
  • git-gui: Moving keyboard focus to “changed files”
  • git server with eclipse project
  • Can I use CodeStar's deployment infrastructure with an existing CodeCommit repo?
  • Pull git contents without the meta content
  • How can I ignore all files except those with a certain extension in git?
  • 4 Solutions collect form web for “Are there any downsides to enabling git rerere?”

    If you do a merge incorrectly, then discard it, then do the “same” merge again, it will be incorrect again. You can forget a recorded resolution, though. From the documentation:

    git rerere forget <pathspec>

    This resets the conflict resolutions which rerere has recorded for the current conflict in <pathspec>.

    Be careful to use it on specific paths; you don’t want to blow away all of your recorded resolutions everywhere. (forget with no arguments has been deprecated to save you from doing this, unless you type git rerere forget . to explicitly request it.)

    But if you don’t think to do that, you could easily end up putting that incorrect merge into your history..

    As J. C. Hamano mentions in his article “Fun with rerere”

    • Rerere remembers how you chose to resolve the conflicted regions;
    • Rerere also remembers how you touched up outside the conflicted regions to adjust to semantic changes;
    • Rerere can reuse previous resolution even though you were merging two branches with different contents than the one you resolved earlier.

    Even people who have been using rerere for a long time often fail to notice the last point.

    So if you activate rerere on too broad a content, you might end up with surprising or confusing merge resolution because of the last point.

    I’ve got rerere globally enabled. I really haven’t noticed any problems, and it usually seems to make my life easier.

    I cherry picked a commit (in gitk) that only contained a binary file. Cherrypick failed due to conflict (which coming to thing about it is natural) and I resolved the conflict keeping the cherry pick. I was surprised later to find in another rebased branch that my dlls did not behave – only to discover they were not carried into the rebase as (I speculate) automatic conflict resolution. So this is the only case I met (having rerere enabled) of running into counterintuitive (though I am sure perfectly consistent) behavior.

    Git Baby is a git and github fan, let's start git clone.