[Existenceblinks]

Nice landing page. I built git-rerere as a service for a company, they only use it internally. The most annoying part of rebase is resolving the same conflict again and again.

.git/rr-cache is the recorded resolutions that help auto resolve the same conflict by matching "preimage" and re-apply "postimage". You could add this feature, it's a killer even github doesn't have a way to feed in rr-cache.

[masukomi]

in general, if you're solving the same conflict over and over it's because of a common conflict resolution misconception / poor choice.

let's say you have commits a->b->c->d

you go to merge and there's a conflict in "a" and instead of taking the choice that would be the precursor to "b" you take a choice (or manually change the merge) that is essentially "d", because that's what you want that code line to look like eventually anyway.

now when git goes to apply the transform from a->b the "a" shaped code it's looking for isn't there because it's "d" shaped, and then when it goes to apply the transform from "b" to "c" ... same problem. and then "c" to "d" ends up being a no-op.

So, if you are resolving the same conflict over and over. Stop. abort your rebase. restart the rebase and when you get to the first conflict in that place make a choice that will help find what it needs to make the next transform in the chain. Do NOT jump ahead.

pro-tip: open up a 2nd terminal. do git log that goes back beyond all your commits.

then when you hit a conflict in the 1st terminal you can `git log -n1` to see what one it has finished applying. then diff between that commit and the next one in a different terminal using the hashes in your git log. this way you can see what's coming and how far you are in the process. and run diffs using the hashes to see what transforms are coming up.

[Existenceblinks]

> Do NOT jump ahead

True, that's the gist. Though the problem I built the app to solve is quite more complex. It's a rebase all opened pull requests altogether with fresh master every time, every branch is done in immutable way (each branch has a shadow branch of itself). And the bundled branch gets shipped to staging server. Each PR can be marked/remarked as included/excluded for each build (akin to CI).

What I mean by "again and again" is for a full cycle again, not "again" in next commit while rebasing. For example, if you already fixed things while rebase, and you abort in the middle, and you start rebase again, now you start at where you aborted.

[johndoughy]

Appreciate the suggestion, that's a great idea. I wasn't familiar with rerere until I started this project but it looks like a useful feature.

[eddd-ddde]

I have to agree, that is a damn good looking site; sometimes I wonder how people can come up with designs like that.

[johndoughy]

Aw shucks, I spent far too long making it, but your comment makes it all worth it =)