Configuring rerere makes a huge difference in overall rebase experience. The following is a standard addition to my gitconfig
[rerere]
enabled = true
autoupdate = trueGitButler now supports first class conflicts, making rebasing less annoying
11–20 of 116 posts
Re: GitButler now supports first class conflicts, making rebasing less annoying
#12Serious question: how many times the pain of going through rebases rather than merges made a difference, or even better, really paid off in engineering terms? To me it's virtually zero in seven years but it might be due to the teams and projects I've been involved with.
It always seemed like a needless complexity when you can just merge and get the same result in terms of the state of the files, just with a different commit history.
The only time it might make sense if you are following some arbitrary strict style guidelines for commits. Some people care more about the commit history than others, not that either way is necessarily better.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#13Serious question: how many times the pain of going through rebases rather than merges made a difference, or even better, really paid off in engineering terms? To me it's virtually zero in seven years but it might be due to the teams and projects I've been involved with.
It's a big deal when maintaining a fork. It's tempting to merge upstream commits back into your branch, but you should always rebase and keep a clean patch set in such situation.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#14Serious question: how many times the pain of going through rebases rather than merges made a difference, or even better, really paid off in engineering terms? To me it's virtually zero in seven years but it might be due to the teams and projects I've been involved with.
I think you're doing it wrong. The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means you'll resolve any conflicts as soon as they happen, while it's still fresh in everyone's heads. If you rebase once right at the end then, sure, it's no different to merging.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#15I have yet to try Jujutsu or GitButler, but Git has a built-in way to make conflict resolution a bit easier with `rerere`. To be honest, I don't find doing this work manually a major chore, so I don't enable it, but it's there if you need it. I would like to comment on this: > I have been asked countless times if it's better to merge or to rebase and while I never want to stir up a hornet's nest, I have always advoca…
Force push should be “with lease” by default. Then force pushing is not dangerous at all.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#16With syslog, everything in git is "fearless"
Did you mean reflog? Either way, even simpler, imho, than any log that one has to comb through after the fact is to create a named backup branch=$(git branch --show-current) && git switch -c backup-${branch} && git switch - Carry on as planned and if you bork it all, switch to the backup branch which retains the original commits and all, delete the borked one and have another go git switch backup-somebranch && git br…
I do this as well but `git reset --hard backup-somebranch` and try again if I mess it up.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#17Serious question: how many times the pain of going through rebases rather than merges made a difference, or even better, really paid off in engineering terms? To me it's virtually zero in seven years but it might be due to the teams and projects I've been involved with.
It isn’t always harder than doing a merge.
> really paid off in engineering terms?
When you want your changes accepted by upstream and they either
1. Won’t accept a merge-filled history
2. Indirectly won’t because they accept changes by email (can’t send merges by email)
Re: GitButler now supports first class conflicts, making rebasing less annoying
#18With syslog, everything in git is "fearless"
As long as you commit everything, yes. The reflog is the safety rope of git. Everyone who isn't confident with the reflog should go and learn it right now.
Pick your most important repo. Make sure everything is committed. Doing something stupid like `git reset --hard HEAD~100`. Look how fucked your work is. Do `git reset --hard HEAD@{1}`. Look at how nothing was lost.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#19With syslog, everything in git is "fearless"
Did you mean reflog? Either way, even simpler, imho, than any log that one has to comb through after the fact is to create a named backup branch=$(git branch --show-current) && git switch -c backup-${branch} && git switch - Carry on as planned and if you bork it all, switch to the backup branch which retains the original commits and all, delete the borked one and have another go git switch backup-somebranch && git br…
You don’t have to comb through the reflog for the pre-rebase branch state. Use `@{1}` from the reflog of the branch (not `HEAD`).[1]
Note: First I thought that `ORIG_HEAD` was the thing. But that won’t work if you did `git reset` during the rebase.
(`ORIG_HEAD` is probably “original head”, not “origin head” (like the remote) that I first thought…)
[1] You just have to comb through documentation!
Re: GitButler now supports first class conflicts, making rebasing less annoying
#20I have yet to try Jujutsu or GitButler, but Git has a built-in way to make conflict resolution a bit easier with `rerere`. To be honest, I don't find doing this work manually a major chore, so I don't enable it, but it's there if you need it. I would like to comment on this: > I have been asked countless times if it's better to merge or to rebase and while I never want to stir up a hornet's nest, I have always advoca…
Force push should be “with lease” by default. Then force pushing is not dangerous at all.
It’s still dangerous if you have fetched recently. You also might want `--force-if-includes`.
(And then I don’t think there are any more “force” flags left to worry about…!)
https://stackoverflow.com/questions/65837109/when-should-i-u...