2 ms·

I am a merger not a rebaser but it is probably a tab/space level personal quirks distinction!

hmeh 3y ago
It’s not. They are different things and have different purposes. Saying you’re a merger is like saying you’re a left turner. You can be an ambiturner. Here’s a quick guide: Working on a feature branch with someone else and you have local commits and they have remote commits? Rebase Need to rewrite history? Rebase For just about everything else, there’s merge.
- quickthrower2 3y ago
  The information preserved by a merge is greater than or equal to that of a rebase. Since you can construct the rebase from a merge. Further, it allows you to work on changes that have been committed on main since you started the work. The downside is there can be dragons in the merge commit (you can make arbitrary changes there) so it requires discipline. I only rebase if the merges conflict and therefore introduce a chance for dragons. So, yeah sometimes I turn right.
  - hmeh 3y ago
    I tend to think it's better to have merge conflict changes be in a merge commit. That way the original commits are still present and if there was a mistake made, it'll be in its own commit. Contrast that w/ rebasing, where the original commit goes away and gets modified to account for the conflict. Compound this w/ the fact that when you rebase you may have to resolve related merge conflicts in multiple commits, and I think rebasing to deal with merge conflicts is the opposite direction of what I would recommend.
    - quickthrower2 3y ago
      I think it depends why the conflict happened. If it happened because say someone else did a refactor then rebasing on that refactor (and that might actually mean manually doing a lot of stuff) is easy to inspect. The problem comes through as a commit with something weird unrelated to the change. It does require line by line code review by the coder, which few might want to do, but I like to do before opening any PR. Because in any case it is so easy to have an editor window open while your cat walks on the keyboard and pastes your password, or whatever :-).
      - hmeh 3y ago
        Honestly, we have so many repositories and such high communication between work cells that merge conflicts are exceedingly rare. If someone did change something out from under me, I could very well see myself doing my work over on top of theirs, and a rebase may help with that, but I would certainly try to merge first. I tend to use rebase solely when I specifically want to rewrite history so as to pretend it was different than it was. Thanks for engaging and discussing!
        quickthrower2 3y ago
        I agree it is rare. And rarer when you learn to make your PRs smaller!
        deleted 3y ago
        [deleted]

hmeh 3y ago

It’s not. They are different things and have different purposes. Saying you’re a merger is like saying you’re a left turner. You can be an ambiturner. Here’s a quick guide: Working on a feature branch with someone else and you have local commits and they have remote commits? Rebase Need to rewrite history? Rebase For just about everything else, there’s merge.

quickthrower2 3y ago
The information preserved by a merge is greater than or equal to that of a rebase. Since you can construct the rebase from a merge. Further, it allows you to work on changes that have been committed on main since you started the work. The downside is there can be dragons in the merge commit (you can make arbitrary changes there) so it requires discipline. I only rebase if the merges conflict and therefore introduce a chance for dragons. So, yeah sometimes I turn right.
- hmeh 3y ago
  I tend to think it's better to have merge conflict changes be in a merge commit. That way the original commits are still present and if there was a mistake made, it'll be in its own commit. Contrast that w/ rebasing, where the original commit goes away and gets modified to account for the conflict. Compound this w/ the fact that when you rebase you may have to resolve related merge conflicts in multiple commits, and I think rebasing to deal with merge conflicts is the opposite direction of what I would recommend.
  - quickthrower2 3y ago
    I think it depends why the conflict happened. If it happened because say someone else did a refactor then rebasing on that refactor (and that might actually mean manually doing a lot of stuff) is easy to inspect. The problem comes through as a commit with something weird unrelated to the change. It does require line by line code review by the coder, which few might want to do, but I like to do before opening any PR. Because in any case it is so easy to have an editor window open while your cat walks on the keyboard and pastes your password, or whatever :-).
    - hmeh 3y ago
      Honestly, we have so many repositories and such high communication between work cells that merge conflicts are exceedingly rare. If someone did change something out from under me, I could very well see myself doing my work over on top of theirs, and a rebase may help with that, but I would certainly try to merge first. I tend to use rebase solely when I specifically want to rewrite history so as to pretend it was different than it was. Thanks for engaging and discussing!
      - quickthrower2 3y ago
        I agree it is rare. And rarer when you learn to make your PRs smaller!
        deleted 3y ago
        [deleted]