[Etheryte]

Somehow, despite using Git for who knows how many years, I haven't seen rerere yet. I read the manpage for it, but the usage isn't exactly clear about any possible pitfalls. Are there any gotchas? Where and how do you usually use it?

[mplanchard]

I generally just enable the above config, which uses it automatically when doing rebases. So, if I’m rebasing a bunch of commits, and I’ve already resolved a set of conflicts once, it just uses that resolution again.

If you want to have it forget a recorded resolution, for example because you messed something up, there are commands for that, but I use them very seldomly.

I’ve never run into any particular pitfalls to speak of. I mostly just turn it on and forget it’s there. You can still always go back in time with the reflog if needed.

[wakawaka28]

You don't have to do anything besides turning it on. If a conflict has been resolved before, somehow it remembers that and applies the fix. The only pitfall I've seen is if you fix the conflict erroneously, it will remember that too.

[PaulDavisThe1st]

Yes, my general rule of thumb as a rerere user and devotee is to at the very least do a test build before git-add'ing your resolved files. You won't catch logical errors, but you will catch syntactical issues that came up during conflict resolution. It helps, a bit.

[mplanchard]

If you accidentally record an incorrect resolution, you can also run `git rerere clear` to clear the cache, or `git rere forget <path>` to forget resolutions just for a particular file.

[PaulDavisThe1st]

Yeah, I learned about this last weekend, after mistakenly trying to rebase a repo where we generally merge.

I don't think that rerere offers fine grained enough control over "forgetting". What I needed (until I realized my mistake) was a way to clear any memory of a resolution for the current conflict in path.