18 ms·

Every git talk everywhere, everytime, should include "git rerere". http://git-scm.com/blog/2010/03/08/rerere.html http://git-scm.com/blog/2010/03/08/rerere.html

• jedbrown 13y ago
  Indeed, but rerere is tricky to explain because it goes hand-in-hand with a workflow that integrates topic branches via an integration branch that is not permanent ('next' in git.git). Despite its numerous unique benefits, it usually takes people a while to understand this workflow.
• Anderkent 13y ago
  To verify that I get it right, the advantage is that with rerere you can merge master into your topic branch, fix all conflicts at once, then have rerere reuse those fixes when you rebase your branch onto master? I don't suppose it's smart enough to work even if your branch has changed a conflicting file multiple times (i.e. the conflict you see in `git merge` is different than the first conflict you get in rebase, for that particular file).
• oneandoneis2 13y ago
  I dislike rerere because it's very difficult to get it to stop remembering your mistakes. I've always found it causes more hassle than it solves.
  • maw 13y ago
    Nod. I use it and appreciate it, but I'm not entirely satisfied with it either for just this reason. It certainly isn't the last word in its space.