GitButler now supports first class conflicts, making rebasing less annoying
1–10 of 116 posts
Re: GitButler now supports first class conflicts, making rebasing less annoying
#2I was looking forward to trying this out, unfortunately Tauri dropped support for Ubuntu 20.04, and thus GitButler did as well: https://github.com/gitbutlerapp/gitbutler/issues/4881
Re: GitButler now supports first class conflicts, making rebasing less annoying
#3With syslog, everything in git is "fearless"
Re: GitButler now supports first class conflicts, making rebasing less annoying
#4With 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 -
git switch backup-somebranch && git branch -D somebranch && git branch -m somebranchRe: GitButler now supports first class conflicts, making rebasing less annoying
#5With syslog, everything in git is "fearless"
Assuming this is the reflog, this is not true. Because the working copy doesn't get snapshotted, it is relatively easy to lose uncommitted data. I've spent much of my professional career working on source control and even I've lost uncommitted data a few times.
Dropbox doesn't have a notion of uncommitted data. Why should source control?
Re: GitButler now supports first class conflicts, making rebasing less annoying
#6With syslog, everything in git is "fearless"
Long rebases are not. That's the whole point.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#7With 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 have a custom bash function named "backup_branch" that does exactly that, along with "restore_backup" and "delete_backups". It's made my life 10x simpler.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#8I was looking forward to trying this out, unfortunately Tauri dropped support for Ubuntu 20.04, and thus GitButler did as well: https://github.com/gitbutlerapp/gitbutler/issues/4881
Ubuntu itself is only supporting 20.04 for another 6 months (unless you pay).
Re: GitButler now supports first class conflicts, making rebasing less annoying
#9Serious 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.
Re: GitButler now supports first class conflicts, making rebasing less annoying
#10I 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 advocated merging over rebasing.
I've been involved in this discussion many times as well, and the correct answer is that one isn't inherently "better", and you shouldn't _always_ prefer one over the other. There are situations when a merge is preferable (e.g. to keep a branch in history), and others when a rebase is (e.g. to, well, _base_ some work on a specific commit). The choice of when to use either will depend on the author's or team's preference in each case, which is why it's given as an option in most web-based PR/MR workflows. Squashing is another task you don't want to always do either.
I partly blame this confusion on Git's UI, and on the baseless fears spread about rebasing for years, which many developers mistakenly absorbed. The amount of times I've heard that force-pushing after a rebase is "dangerous" is too high. No wonder people find it scary...