9 ms·

GitButler now supports first class conflicts, making rebasing less annoying

109 points by hemogloben 2y ago

hemogloben 2y ago
I 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 https://github.com/gitbutlerapp/gitbutler/issues/4881
- sevg 2y ago
  Ubuntu itself is only supporting 20.04 for another 6 months (unless you pay).
johnea 2y ago
With syslog, everything in git is "fearless"
- Yasuraka 2y ago
  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 branch -D somebranch && git branch -m somebranch
  - 0xCAP 2y ago
    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.
  - Pfiffer 2y ago
    I do this as well but `git reset --hard backup-somebranch` and try again if I mess it up.
  - keybored 2y ago
    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!
- sunshowers 2y ago
  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?
  - hinkley 2y ago
    I have to use reflog, rebase -i and frequent commits to cover the spectrum of edge cases I deal with weekly. No two of them accomplish the entire job.
    - sunshowers 2y ago
      You should try out Jujutsu :)
      - hinkley 2y ago
        It's on my list.
- IshKebab 2y ago
  Long rebases are not. That's the whole point.
- globular-toast 2y ago
  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.
  - everybodyknows 2y ago
    > reflog should go and learn it Among its other virtues, reflog makes safe the highly empowering 'git-commit --amend'.
    - globular-toast 2y ago
      Yep, and even the more powerful fixup workflow where you can essentially amend commits other than HEAD. I do it via git-autofixup: https://github.com/torbiak/git-autofixup https://github.com/torbiak/git-autofixup
epolanski 2y ago
Serious 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.
- hansonkd 2y ago
  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.
  - wakawaka28 2y ago
    A linear commit history is objectively better. But whether it's worth the effort to maintain is up to you to decide. If your branches don't stay unmerged for long, then you're probably better off rebasing instead of generating tons of little branches for no reason.
    - hansonkd 2y ago
      Objectively better to what? Git usage is only one part of a wider engineering org. That like saying "bugless code is objectively better" without considering time to delivery, engineering resources, etc.
      - rontdrr2 2y ago
        [dead]
      - wakawaka28 2y ago
        Better to work with of course. If you have valid reasons to have branches, such as a need to ship multiple versions, I don't have a problem with that. But day-to-day work is better done via rebasing rather than making a ton of public branches that get merged. If you know what you're doing then rebasing is just as easy as merging. As others have said, git rerere helps a lot too.
imiric 2y ago
I 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...
- frizlab 2y ago
  Force push should be “with lease” by default. Then force pushing is not dangerous at all.
  - keybored 2y ago
    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-use-git-push-force-if-includes/71414529#71414529 https://stackoverflow.com/questions/65837109/when-should-i-u...
    - hughesjj 2y ago
      I really wish there was a global setting to turn this on by default/in config but afaik for backwards compatibility reasons Linus doesn't want to do that so the advice I've heard is to just configure it as an alias Personally, I'm lazy and just always have it in recent substring match history in the shell
mplanchard 2y ago
Configuring rerere makes a huge difference in overall rebase experience. The following is a standard addition to my gitconfig [rerere] enabled = true autoupdate = true
- Etheryte 2y ago
  Somehow, despite using Git for who knows how many years, I haven't seen rerere yet. I read the manpage for it, but the usage isn't exactly clear about any possible pitfalls. Are there any gotchas? Where and how do you usually use it?
  - wakawaka28 2y ago
    You don't have to do anything besides turning it on. If a conflict has been resolved before, somehow it remembers that and applies the fix. The only pitfall I've seen is if you fix the conflict erroneously, it will remember that too.
    - PaulDavisThe1st 2y ago
      Yes, my general rule of thumb as a rerere user and devotee is to at the very least do a test build before git-add'ing your resolved files. You won't catch logical errors, but you will catch syntactical issues that came up during conflict resolution. It helps, a bit.
      - mplanchard 2y ago
        If you accidentally record an incorrect resolution, you can also run `git rerere clear` to clear the cache, or `git rere forget <path>` to forget resolutions just for a particular file.
        PaulDavisThe1st 2y ago
        Yeah, I learned about this last weekend, after mistakenly trying to rebase a repo where we generally merge. I don't think that rerere offers fine grained enough control over "forgetting". What I needed (until I realized my mistake) was a way to clear any memory of a resolution for the current conflict in path.
_ugfj 2y ago
I must admit I usually immediately disregard any fancy new git tools, they come and go and often don't work right and create a gigantic mess. But... have you seen who wrote this article? Scott Chacon. If there's anyone in this world whose article would make me try a new git tool, it's him. He wrote the Pro Git book, Git Internals. Oh and cofounded GitHub. This is not argument from authority fallacy. This is "hey! this guy knows git like very very few others, it's worth listening to what he has to say".
- lmm 2y ago
  More importantly IMO he wrote the github-flow post, the best dose of sanity in git workflows I've seen.
  - _ugfj 2y ago
    and yet these fuckers downvoted my post without commenting where I am wrong
- eviks 2y ago
  This is precisely the argument from authority fallacy, though a bit more grounded than the strong prejudice with a gigantic mess
- obeavs 2y ago
  Gitbutler is ridiculously cool and well considered. Definitely worth checking out.
- keybored 2y ago
  It’s precisely that which makes me skeptical of it. > For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal. > ... > I don't know exactly what the answer is, but the sad truth of Git is that writing amazing documentation via commit message, for most communities, is almost entirely a waste of time. It's just too difficult to find them. https://news.ycombinator.com/item?id=39218538 https://news.ycombinator.com/item?id=39218538
ibejoeb 2y ago
A talk about gitbutler on the devtools-fm podcast: https://www.youtube.com/watch?v=I-D6zChu3YI https://www.youtube.com/watch?v=I-D6zChu3YI
mdaniel 2y ago
cute: https://github.com/gitbutlerapp/gitbutler/blob/v0.10.0/LICENSE.md#functional-source-license-version-10-mit-change-license https://github.com/gitbutlerapp/gitbutler/blob/v0.10.0/LICEN...
- ilyagr 2y ago
  They have a few blog posts about this license: https://blog.gitbutler.com/gitbutler-is-now-fair-source/ https://blog.gitbutler.com/gitbutler-is-now-fair-source/, https://blog.gitbutler.com/the-future-of-open-source/ https://blog.gitbutler.com/the-future-of-open-source/ I don't think they are the first ones to open-source their code on a timer, but they are trying to popularize the idea.
dimal 2y ago
Off topic but why do product blogs always exist on a separate domain, with no link to the product website? I never heard of GitButler. Reading this is making me curious about it. But the home link in the top left goes to the blog home. If I want to actually see the product, I have to manually edit the url, on my iPad. Why does everyone do this? Seems obvious to have a link to the main site. /rant
- nguyenkien 2y ago
  Home website link in menu button.
User23 2y ago
As an aside you can avoid the vast majority of unnecessary rebase tedium with proper use of git rebase —onto
eviks 2y ago
At least one example of a conflicted hunk and what exactly gets saved would be more useful than a full screen screenshot just to show a single "conflicted" button in the UI

109 points by hemogloben 2y ago

I 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 https://github.com/gitbutlerapp/gitbutler/issues/4881

sevg 2y ago
Ubuntu itself is only supporting 20.04 for another 6 months (unless you pay).

johnea 2y ago

With syslog, everything in git is "fearless"

Yasuraka 2y ago
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 branch -D somebranch && git branch -m somebranch
- 0xCAP 2y ago
  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.
- Pfiffer 2y ago
  I do this as well but `git reset --hard backup-somebranch` and try again if I mess it up.
- keybored 2y ago
  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!
sunshowers 2y ago
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?
- hinkley 2y ago
  I have to use reflog, rebase -i and frequent commits to cover the spectrum of edge cases I deal with weekly. No two of them accomplish the entire job.
  - sunshowers 2y ago
    You should try out Jujutsu :)
    - hinkley 2y ago
      It's on my list.
IshKebab 2y ago
Long rebases are not. That's the whole point.
globular-toast 2y ago
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.
- everybodyknows 2y ago
  > reflog should go and learn it Among its other virtues, reflog makes safe the highly empowering 'git-commit --amend'.
  - globular-toast 2y ago
    Yep, and even the more powerful fixup workflow where you can essentially amend commits other than HEAD. I do it via git-autofixup: https://github.com/torbiak/git-autofixup https://github.com/torbiak/git-autofixup

epolanski 2y ago

Serious 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.

hansonkd 2y ago
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.
- wakawaka28 2y ago
  A linear commit history is objectively better. But whether it's worth the effort to maintain is up to you to decide. If your branches don't stay unmerged for long, then you're probably better off rebasing instead of generating tons of little branches for no reason.
  - hansonkd 2y ago
    Objectively better to what? Git usage is only one part of a wider engineering org. That like saying "bugless code is objectively better" without considering time to delivery, engineering resources, etc.
    - rontdrr2 2y ago
      [dead]
    - wakawaka28 2y ago
      Better to work with of course. If you have valid reasons to have branches, such as a need to ship multiple versions, I don't have a problem with that. But day-to-day work is better done via rebasing rather than making a ton of public branches that get merged. If you know what you're doing then rebasing is just as easy as merging. As others have said, git rerere helps a lot too.

imiric 2y ago

I 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...

frizlab 2y ago
Force push should be “with lease” by default. Then force pushing is not dangerous at all.
- keybored 2y ago
  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-use-git-push-force-if-includes/71414529#71414529 https://stackoverflow.com/questions/65837109/when-should-i-u...
  - hughesjj 2y ago
    I really wish there was a global setting to turn this on by default/in config but afaik for backwards compatibility reasons Linus doesn't want to do that so the advice I've heard is to just configure it as an alias Personally, I'm lazy and just always have it in recent substring match history in the shell

mplanchard 2y ago

Configuring rerere makes a huge difference in overall rebase experience. The following is a standard addition to my gitconfig [rerere] enabled = true autoupdate = true

Etheryte 2y ago
Somehow, despite using Git for who knows how many years, I haven't seen rerere yet. I read the manpage for it, but the usage isn't exactly clear about any possible pitfalls. Are there any gotchas? Where and how do you usually use it?
- wakawaka28 2y ago
  You don't have to do anything besides turning it on. If a conflict has been resolved before, somehow it remembers that and applies the fix. The only pitfall I've seen is if you fix the conflict erroneously, it will remember that too.
  - PaulDavisThe1st 2y ago
    Yes, my general rule of thumb as a rerere user and devotee is to at the very least do a test build before git-add'ing your resolved files. You won't catch logical errors, but you will catch syntactical issues that came up during conflict resolution. It helps, a bit.
    - mplanchard 2y ago
      If you accidentally record an incorrect resolution, you can also run `git rerere clear` to clear the cache, or `git rere forget <path>` to forget resolutions just for a particular file.
      - PaulDavisThe1st 2y ago
        Yeah, I learned about this last weekend, after mistakenly trying to rebase a repo where we generally merge. I don't think that rerere offers fine grained enough control over "forgetting". What I needed (until I realized my mistake) was a way to clear any memory of a resolution for the current conflict in path.

_ugfj 2y ago

I must admit I usually immediately disregard any fancy new git tools, they come and go and often don't work right and create a gigantic mess. But... have you seen who wrote this article? Scott Chacon. If there's anyone in this world whose article would make me try a new git tool, it's him. He wrote the Pro Git book, Git Internals. Oh and cofounded GitHub. This is not argument from authority fallacy. This is "hey! this guy knows git like very very few others, it's worth listening to what he has to say".

lmm 2y ago
More importantly IMO he wrote the github-flow post, the best dose of sanity in git workflows I've seen.
- _ugfj 2y ago
  and yet these fuckers downvoted my post without commenting where I am wrong
eviks 2y ago
This is precisely the argument from authority fallacy, though a bit more grounded than the strong prejudice with a gigantic mess
obeavs 2y ago
Gitbutler is ridiculously cool and well considered. Definitely worth checking out.
keybored 2y ago
It’s precisely that which makes me skeptical of it. > For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal. > ... > I don't know exactly what the answer is, but the sad truth of Git is that writing amazing documentation via commit message, for most communities, is almost entirely a waste of time. It's just too difficult to find them. https://news.ycombinator.com/item?id=39218538 https://news.ycombinator.com/item?id=39218538

ibejoeb 2y ago

A talk about gitbutler on the devtools-fm podcast: https://www.youtube.com/watch?v=I-D6zChu3YI https://www.youtube.com/watch?v=I-D6zChu3YI

mdaniel 2y ago

cute: https://github.com/gitbutlerapp/gitbutler/blob/v0.10.0/LICENSE.md#functional-source-license-version-10-mit-change-license https://github.com/gitbutlerapp/gitbutler/blob/v0.10.0/LICEN...

ilyagr 2y ago
They have a few blog posts about this license: https://blog.gitbutler.com/gitbutler-is-now-fair-source/ https://blog.gitbutler.com/gitbutler-is-now-fair-source/, https://blog.gitbutler.com/the-future-of-open-source/ https://blog.gitbutler.com/the-future-of-open-source/ I don't think they are the first ones to open-source their code on a timer, but they are trying to popularize the idea.

dimal 2y ago

Off topic but why do product blogs always exist on a separate domain, with no link to the product website? I never heard of GitButler. Reading this is making me curious about it. But the home link in the top left goes to the blog home. If I want to actually see the product, I have to manually edit the url, on my iPad. Why does everyone do this? Seems obvious to have a link to the main site. /rant

nguyenkien 2y ago
Home website link in menu button.

User23 2y ago

As an aside you can avoid the vast majority of unnecessary rebase tedium with proper use of git rebase —onto

eviks 2y ago

At least one example of a conflicted hunk and what exactly gets saved would be more useful than a full screen screenshot just to show a single "conflicted" button in the UI