3 ms·

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 rebas

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.

switchbak 2y ago
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.
- joshuanapoli 2y ago
  I haven't used Magit or GitUp, but I really appreciate JetBrains IDE automatic conflict resolver.
- quibono 2y ago
  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.
- bigstrat2003 2y ago
  > 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.
  - Izkata 2y ago
    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.
sjburt 2y ago
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.
- felixhummel 2y ago
  You might like rerere: https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere

switchbak 2y ago

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.

joshuanapoli 2y ago
I haven't used Magit or GitUp, but I really appreciate JetBrains IDE automatic conflict resolver.
quibono 2y ago
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.
bigstrat2003 2y ago
> 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.
- Izkata 2y ago
  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.

sjburt 2y ago

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.

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