Hacker News Reader

Comment by quibono | Hacker News Reader

Personally I am squarely in the rebase team although I'm not completely anti-merge. I find the interactive rebase to be so useful that I pretty much never rebase non-interactively. I wonder if part of the reason the merge flow is more popular (or at least it seems more popular) is because native Git tooling around rebasing isn't the best. In fact doing anything more than the simple reword/squash/reorder (like commit splitting or moving chunks between commits) is abysmal. Magit really shines here and makes it a breeze.

View on HN

The main issue is that on a longer branch, you have to fix all the rebase conflicts on the oldest commit. Then, if you changed something in the conflict zone, you fix it again on the next commit, because the next commit used to be based on something else. Sometimes git rerere can help with this, but I find it fairly unreliable (could be user error!) If you do a merge, you only need to resolve it all once.

Otherwise I tend to prefer rebase.

You might like rerere: https://git-scm.com/book/en/v2/Git-Tools-Rerere

I think Git's roots show in its lack of DX. But I'll take it over the horror that was SVN and prior tooling.

Question: how does Magit compare to GitUp? The latter is my benchmark for complex rebases, but I'd love to know if I'm stuck in a local optima.

I haven't used Magit or GitUp, but I really appreciate JetBrains IDE automatic conflict resolver.

I've not used GitUp so I'm not sure how much help this will be to you since I can't objectively compare the two. As an example, let's say I want to remove some changes from a commit (and potentially move those into one or more different commits). If I go into the commit and select the chunks I want to revert, I can click `u` and right away I get the revert chunk added into my staging area AND the original chunk added to my working tree. Then I just fix-up the original commit (c F) to remove the unwanted change, and commit the original change - either in a few different commits or possibly just one.

> I think Git's roots show in its lack of DX. But I'll take it over the horror that was SVN and prior tooling.

This statement really confuses me. SVN was so much easier to use than git. It was incredibly straightforward: make changes, commit, done.

Merging branches was roughly the equivalent of git cherry-pick. There's tracking to prevent you from pulling the same commit twice, but not much else.

--reintegrate was introduced later, and even with that it was easy to get wrong.

Reply on news.ycombinator.com