[HN Gopher] GitButler now supports first class conflicts, making...
___________________________________________________________________
GitButler now supports first class conflicts, making rebasing less
annoying
Author : hemogloben
Score : 58 points
Date : 2024-10-23 16:57 UTC (6 hours ago)
(HTM) web link (blog.gitbutler.com)
(TXT) w3m dump (blog.gitbutler.com)
| hemogloben wrote:
| 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
| sevg wrote:
| Ubuntu itself is only supporting 20.04 for another 6 months
| (unless you pay).
| johnea wrote:
| With syslog, everything in git is "fearless"
| Yasuraka wrote:
| 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 wrote:
| 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 wrote:
| I do this as well but `git reset --hard backup-somebranch`
| and try again if I mess it up.
| keybored wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| You should try out Jujutsu :)
| IshKebab wrote:
| Long rebases are not. That's the whole point.
| globular-toast wrote:
| 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.
| epolanski wrote:
| 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 wrote:
| 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 wrote:
| 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.
| PhilipRoman wrote:
| 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.
| globular-toast wrote:
| 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.
| epolanski wrote:
| I'm not doing it wrong, I'm questioning whether it's worth
| the effort.
|
| I have spent hours rebasing on very active branches when a
| merge would've taken minutes (as many colleagues do) just
| because "it's a best practice" but I've never got to fully
| appreciate the reason.
| keybored wrote:
| 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)
| hinkley wrote:
| I spend a lot of time cleaning up after people who insist there
| are no b problems in their code despite all evidence to the
| contrary.
|
| That work is easier when they haven't squashed their changes.
| Because I can see how they got there and if it was a mistake or
| a misunderstanding.
|
| People who prefer squash are an automatic red flag because they
| usually don't like asking Why, which is a very important skill
| on products that are shipping and making money.
| epolanski wrote:
| Issues should be catched by spending time in automating tests
| that ensure the correct functional and non functional
| requirements are met not by surgically maintaining a graph of
| codebase snapshots.
|
| History is preserved in the branch along the PRs if needed,
| and it rarely is.
|
| I'm not saying that rebasing is useless (I default to it),
| I'm debating if the effort is worth it in engineering terms,
| which I generally don't see because the benefits seem to be
| small compared to the cost.
| wakawaka28 wrote:
| >That work is easier when they haven't squashed their
| changes. Because I can see how they got there and if it was a
| mistake or a misunderstanding.
|
| That sounds like a problem with the people you work with, not
| with squashing in general.
|
| >People who prefer squash are an automatic red flag because
| they usually don't like asking Why, which is a very important
| skill on products that are shipping and making money.
|
| This is a wild generalization. Thoughtful people squash when
| they think they have a set of changes that go together. If
| someone is jamming together stuff that does not go together
| then that is indeed a problem, but not a problem with squash.
| Nobody really wants to see the 50 edits someone made to come
| up with one final change (or perhaps a couple of commits).
| imiric wrote:
| 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 wrote:
| Force push should be "with lease" by default. Then force
| pushing is not dangerous at all.
| keybored wrote:
| 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/a/71414529/1725151
| mplanchard wrote:
| 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 wrote:
| 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?
| chx wrote:
| 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".
| ibejoeb wrote:
| A talk about gitbutler on the devtools-fm podcast:
| https://www.youtube.com/watch?v=I-D6zChu3YI
| mdaniel wrote:
| cute:
| https://github.com/gitbutlerapp/gitbutler/blob/v0.10.0/LICEN...
___________________________________________________________________
(page generated 2024-10-23 23:00 UTC)