Hey HN, I've long wished that git rebase was less tedious, so I made a tool called 'debase' to help make it easier.
debase lets you edit your git repo using drag and drop in your terminal. I didn't want a full GUI because I prefer using git from the terminal, but rebasing is often easier when done visually rather than textually. So debase tries to fill that gap.
debase supports macOS (x86_64 / arm64) and Linux (x86_64). I spent a fair amount of time on it so I decided to make it shareware ($10) but it has a 7-day trial.
Anyway, would love to hear your thoughts and suggestions.
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.
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.
[+] [-] johndoughy|3 years ago|reply
debase lets you edit your git repo using drag and drop in your terminal. I didn't want a full GUI because I prefer using git from the terminal, but rebasing is often easier when done visually rather than textually. So debase tries to fill that gap.
debase supports macOS (x86_64 / arm64) and Linux (x86_64). I spent a fair amount of time on it so I decided to make it shareware ($10) but it has a 7-day trial.
Anyway, would love to hear your thoughts and suggestions.
[+] [-] Existenceblinks|3 years ago|reply
.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|3 years ago|reply
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.
[+] [-] johndoughy|3 years ago|reply
[+] [-] eddd-ddde|3 years ago|reply