3 ms·

Fixing up merge conflicts multiple times when rebasing is indeed a huge pain (has anyone actually used git rerere? If I ever find myself in this situation I alw

Fixing up merge conflicts multiple times when rebasing is indeed a huge pain (has anyone actually used git rerere? If I ever find myself in this situation I always just squash first instead.) However I typically squash by just doing a soft `git reset` to the merge-base (the last commit in common with my branch and the one I'm building my work from) and making a new commit. It avoids touching the working tree at all, which avoids breaking my build cache and confusing my IDE. If I instead want to do a squash-rebase onto the _latest_ of the upstream branch, I do the same as the above, except I `git merge` first (to resolve any merge conflicts in one shot.) Then the merge-base is just the upstream head. This is way easier than doing `rebase -i` and squashing, because you don't have to fix the merge conflicts over and over again for every commit you're trying to squash... just fix the merge conflicts once during the merge, and the "reset and commit" trick is going to create one clean commit in the end anyway.

secondcoming 5y ago
Man, this is way too complex for me.
- mpawelski 5y ago
  The wording might seems complex (I still had to think about what is "upstream" and "merge-base" since I'm not using this terms very often but the main idea the author proposed is quite simple and brilliant if you know "how git works" and what "git reset" does. I don't do it but I like it a lot :) Probably many git users works like this because it all makes sense. The commands will look like that if you want to just squash your changes: git reset --soft $(git merge-base HEAD origin/master) git commit -m 'squashed commit` and like this if you want to squash and rebase on "upstream" (most likely "master" on "origin" remote), andrewmackrodt already wrote it in another comment: git fetch git merge origin/main git reset --soft origin/main git commit -m 'HN-1337 Awesome new feature' I like this approach (haven't tested it yet!) because as author wrote it doesn't unnecessary change much files in you current working directory, and IDEs sometimes get crazy when you do rebase. Currently, I usually try to write my individual commits to be logical changes grouped together and if I see there are some WIP commits or commits that don't look like one logical change, then I just squash this commits (not whole branch). This helps a little in avoiding unnecessary merge conflicts in rebase, but it's not always perfect solution. I still need to figure out what this "git rerere" magic does though...
cshokie 5y ago
If the interim commits are not interesting (which they often aren’t) then it is definitely a lot easier to wrangle a single commit than multiple. This is good for cherry picks as well. Much easier to pick a single commit than a bunch. I also like the “reset and recommit” approach to squashing in place. It greatly benefits from being easier to explain to coworkers who are less experienced with Git. Reset and especially commit are common operations. Interactive rebase and the text editor that pops up and requires manual editing can be overwhelming for less experienced team members.
LocalPCGuy 5y ago
I've tried rerere in the past. I just never remember exactly how to enable/disable it as needed, so it seemed like it was either off when I need it or auto-fixing something when I don't want it to.
andrewmackrodt 5y ago
I use rerere on all git installations, it's a massive time saver. On the very rare occasion I do want to squash a single commit onto the branch HEAD, I use the same workflow as yourself. Using rebase for that workflow as described in the article isn't necessary IMO. For anyone wondering what that command would look like: git fetch git merge origin/main git reset --soft origin/main git commit -m 'HN-1337 Awesome new feature'
- PaulDavisThe1st 5y ago
  git rerere is the bees knees. it's the sunshine of my life. it's the silving lining to the clouds of rebasing. it's ... well, it's just the absolute shiznit and if you use git, you should have it enabled always. Last year, I finally merged an 18 month "long" dev branch that I had kept up to date with rebasing many times during work on that branch. Why 18 months? Some things just take a long time. git rerere made this easy and almost painless.

secondcoming 5y ago

Man, this is way too complex for me.

mpawelski 5y ago
The wording might seems complex (I still had to think about what is "upstream" and "merge-base" since I'm not using this terms very often but the main idea the author proposed is quite simple and brilliant if you know "how git works" and what "git reset" does. I don't do it but I like it a lot :) Probably many git users works like this because it all makes sense. The commands will look like that if you want to just squash your changes: git reset --soft $(git merge-base HEAD origin/master) git commit -m 'squashed commit` and like this if you want to squash and rebase on "upstream" (most likely "master" on "origin" remote), andrewmackrodt already wrote it in another comment: git fetch git merge origin/main git reset --soft origin/main git commit -m 'HN-1337 Awesome new feature' I like this approach (haven't tested it yet!) because as author wrote it doesn't unnecessary change much files in you current working directory, and IDEs sometimes get crazy when you do rebase. Currently, I usually try to write my individual commits to be logical changes grouped together and if I see there are some WIP commits or commits that don't look like one logical change, then I just squash this commits (not whole branch). This helps a little in avoiding unnecessary merge conflicts in rebase, but it's not always perfect solution. I still need to figure out what this "git rerere" magic does though...

cshokie 5y ago

If the interim commits are not interesting (which they often aren’t) then it is definitely a lot easier to wrangle a single commit than multiple. This is good for cherry picks as well. Much easier to pick a single commit than a bunch. I also like the “reset and recommit” approach to squashing in place. It greatly benefits from being easier to explain to coworkers who are less experienced with Git. Reset and especially commit are common operations. Interactive rebase and the text editor that pops up and requires manual editing can be overwhelming for less experienced team members.

LocalPCGuy 5y ago

I've tried rerere in the past. I just never remember exactly how to enable/disable it as needed, so it seemed like it was either off when I need it or auto-fixing something when I don't want it to.

andrewmackrodt 5y ago

I use rerere on all git installations, it's a massive time saver. On the very rare occasion I do want to squash a single commit onto the branch HEAD, I use the same workflow as yourself. Using rebase for that workflow as described in the article isn't necessary IMO. For anyone wondering what that command would look like: git fetch git merge origin/main git reset --soft origin/main git commit -m 'HN-1337 Awesome new feature'

PaulDavisThe1st 5y ago
git rerere is the bees knees. it's the sunshine of my life. it's the silving lining to the clouds of rebasing. it's ... well, it's just the absolute shiznit and if you use git, you should have it enabled always. Last year, I finally merged an 18 month "long" dev branch that I had kept up to date with rebasing many times during work on that branch. Why 18 months? Some things just take a long time. git rerere made this easy and almost painless.