Show HN: Debase – drag and drop Git rebase in your terminal(heytoaster.com) |
Show HN: Debase – drag and drop Git rebase in your terminal(heytoaster.com) |
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.
.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.
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.
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.