4 ms·

Configuring rerere makes a huge difference in overall rebase experience. The following is a standard addition to my gitconfig [rerere] enabled = true

Configuring rerere makes a huge difference in overall rebase experience. The following is a standard addition to my gitconfig [rerere] enabled = true autoupdate = true

Etheryte 2y ago
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?
- wakawaka28 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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.
- mplanchard 2y ago
  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.

Configuring rerere makes a huge difference in overall rebase experience. The following is a standard addition to my gitconfig [rerere] enabled = true autoupdate = true

Etheryte 2y ago

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?

wakawaka28 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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.
mplanchard 2y ago
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.