5 ms·

Rebase Considered Harmful article is here: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

simiones 4y ago
In my opinion, the worse part of the article is that it only shows the simple cases of feature branch history. In particular, they show the following comparison: Merge: -> C3 -> C5 -> C7 / / C1 -> C2 -> C4 -> C6 Rebase: -> C3 -> C5] -> C3' -> C5' / / C1 -> C2 -> C4 -> C6 However, a more realistic example of a feature branch that lives for even a few days looks like this: Merge: -> C3 -> C5 -> C7 -> C9 -> C11 -> C13 --------> C15 / / / / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 -> C18 The final history after rebase being: -> C3' -> C5' -> C9' -> C13' / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 --------------------------> C18 A much much simpler history to follow, and obviously shorter. And the complexity without rebase grows even more if more people are doing local merges and pushing to the same remote branch.
- crescentfresh 4y ago
  I feel like you inadvertently confirmed the authors point. In your “complicated” example, in order to visually show the baseline after rebase you removed the earlier C3, C5, C7 and C9 commits. But the authors point is that merge commits just need better tooling that can make it clearer what the baseline is!
  - deleted 4y ago
    [deleted]
  - simiones 4y ago
    It's git that removed them, not me: rebase re-writes history, that's the whole point. They simply do not exist in the repo anymore after the rebase operation is committed. In fact, following the same merge history as in the first example, I should have named the final ones C3''', C5''', and C9', since they get re-written several times. But, most of the time, this is entirely irrelevant to their history (especially when they don't even touch the same files as the changes being merged in). Note that C7, C11 and C15 completely disappeared, since they are unnecessary. Instead of being extra commits clogging up the log, they are the history rewrite events that don't need to be consigned.
    - samus 4y ago
      Git can trivially rebase out those merges, but that begs the question why they were even done in the first place. I can imagine that sometimes a feature depends on changes from develop after the start of the feature branch. This means that development started too early. Cherry-picking my changes on to a new branch will hide that fact. Rebasing will conserve the authoring timestamp. I guess it depends on the specific situation what's best. In a trunk-based development workflow, I'd have to merge asap and maybe hide things behind feature flags or compile-time switches to avoid such merges. Things get even more interesting when the merges from develop affected files that were changed on the feature branch. You will likely get conflicts if you attempt to rebase them away.
      - tsimionescu 4y ago
        Multiple features are normally developed in parallel. It's good practice to keep up to date with the latest develop/master to avoid surprises at later stages. Rebasing your work onto the head of master before merging it in, versus cherry-picking the relevant changes from your branch onto the head of master, are perfectly identical in terms of end result - whichever workflow is easier for you will achieve the same thing. And of course you can get conflicts if multiple people are developing over the same files - this will happen regardless of using merge, rebase, or cherry pick (or even patches over email). You fix the conflicts when merging / rebasing / cherry picking / accepting a patch.
    - 4y ago

simiones 4y ago

In my opinion, the worse part of the article is that it only shows the simple cases of feature branch history. In particular, they show the following comparison: Merge: -> C3 -> C5 -> C7 / / C1 -> C2 -> C4 -> C6 Rebase: -> C3 -> C5] -> C3' -> C5' / / C1 -> C2 -> C4 -> C6 However, a more realistic example of a feature branch that lives for even a few days looks like this: Merge: -> C3 -> C5 -> C7 -> C9 -> C11 -> C13 --------> C15 / / / / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 -> C18 The final history after rebase being: -> C3' -> C5' -> C9' -> C13' / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 --------------------------> C18 A much much simpler history to follow, and obviously shorter. And the complexity without rebase grows even more if more people are doing local merges and pushing to the same remote branch.

crescentfresh 4y ago
I feel like you inadvertently confirmed the authors point. In your “complicated” example, in order to visually show the baseline after rebase you removed the earlier C3, C5, C7 and C9 commits. But the authors point is that merge commits just need better tooling that can make it clearer what the baseline is!
- deleted 4y ago
  [deleted]
- simiones 4y ago
  It's git that removed them, not me: rebase re-writes history, that's the whole point. They simply do not exist in the repo anymore after the rebase operation is committed. In fact, following the same merge history as in the first example, I should have named the final ones C3''', C5''', and C9', since they get re-written several times. But, most of the time, this is entirely irrelevant to their history (especially when they don't even touch the same files as the changes being merged in). Note that C7, C11 and C15 completely disappeared, since they are unnecessary. Instead of being extra commits clogging up the log, they are the history rewrite events that don't need to be consigned.
  - samus 4y ago
    Git can trivially rebase out those merges, but that begs the question why they were even done in the first place. I can imagine that sometimes a feature depends on changes from develop after the start of the feature branch. This means that development started too early. Cherry-picking my changes on to a new branch will hide that fact. Rebasing will conserve the authoring timestamp. I guess it depends on the specific situation what's best. In a trunk-based development workflow, I'd have to merge asap and maybe hide things behind feature flags or compile-time switches to avoid such merges. Things get even more interesting when the merges from develop affected files that were changed on the feature branch. You will likely get conflicts if you attempt to rebase them away.
    - tsimionescu 4y ago
      Multiple features are normally developed in parallel. It's good practice to keep up to date with the latest develop/master to avoid surprises at later stages. Rebasing your work onto the head of master before merging it in, versus cherry-picking the relevant changes from your branch onto the head of master, are perfectly identical in terms of end result - whichever workflow is easier for you will achieve the same thing. And of course you can get conflicts if multiple people are developing over the same files - this will happen regardless of using merge, rebase, or cherry pick (or even patches over email). You fix the conflicts when merging / rebasing / cherry picking / accepting a patch.
  - 4y ago