@b0rk there's a trap in bullet 1. of your top left box: to do "git rebase -i" to squash all commits into a single one, you need to give as rebase target commit, the fork commit of your dev branch, not main
I would love to know if there's a concise way to tell git rebase to do that
@b0rk Oh yes, I think point 3 in particular is a golden rule! Rebasing the same branch multiple times and doing one small thing each time is so much more manageable than trying to do it all in one go.
@b0rk Also, on point 5: I recently learnt about ORIG_HEAD, which is a reference to where you were before the last rebase, which makes undoing a rebase much easier ("git reset --hard ORIG_HEAD"), and as a result has made me a lot more relaxed about finishing a rebase that turns out to be tricky.
a bunch of folks have mentioned that they use rerere to avoid solving the same merge conflict a million times during a rebase. If you use it, do you find it works well? are there any downsides to using it?
@b0rk I’ve only used it once, but it worked well. I had to fix a big merge conflict with lots of files, and it gave me comfort to know, “I’ll only have to fix this once.”
@b0rk rerere is great! i turned it on by default everywhere now and barely notice it exists except that some magic happens sometimes. the only downside is if you happen to badly resolve a merge, that might be annoying, and can be a little sticky to fix (because you lost the merge context and forgot rerere exists)
@alatiera@b0rk this -- I usually do a git rebase -i and then block edit in vim to replace all the pick with fixup in one fell swoop (because the string after that first word doesn't actually matter)
@b0rk my usual approach to this is 'git reset --soft HEAD^^^^^' followed by 'git commit' and type a fresh message from scratch. Normally in that situation I didn't particularly want to keep the five old messages anyway…
@b0rk Better yet, I'm still looking for a way to say "squash that last change in with the place where I introduced it". If that was beyond some point (might default to "any remote branch) or there is no clear place where the bug was introduced, that's fine, but I spend way more time than I'd like around small typos finding out which of the 10 commits on my branch I introduced that in.
@b0rk I've only ever had this pick the wrong commits or ones out of range of my change branch. not sure if it's because i do branches weird or something else though.
@atrus do you find rerere works well in practice? are there any downsides? i'm considering including it but i'm always wary of giving advice that I haven't personally tried
Add comment