4 ms·

My only beef with rebasing is that it seems to fail much more often, whereas merges will usually do the right thing. I realize this is git-specific, but rebases

My only beef with rebasing is that it seems to fail much more often, whereas merges will usually do the right thing. I realize this is git-specific, but rebases have still given me much more trouble than merges.

cryptonector 7y ago
I've yet ever to see a rebase workflow fail, and I've been using a rebase workflow since at least 2002. I do sometimes have to rebase across thousands of commits because I let a branch rot, and that can be hard to rebase, but it can be equally difficult to merge. Instead I use a bisecting rebase approach where I try to rebase straight to the new upstream, and if there's conflicts, abort the rebase and try rebasing to halfway to the new upstream, continuing the process until the rebase was across just one commit, thus I can resolve conflicts directly with the upstream commit that caused them, then restart the process until done.
- StavrosK 7y ago
  Hmm, that doesn't match my experience. If I remember correctly, I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again. Merging doesn't have that problem, it usually just merges fine unless there are conficts in the latest commit (not all previous ones).
  - philsnow 7y ago
    > I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again. is this solved by enabling git-rerere ? https://medium.com/@porteneuve/fix-conflicts-only-once-with-git-rerere-7d116b2cec67 https://medium.com/@porteneuve/fix-conflicts-only-once-with-...
    - cryptonector 7y ago
      No, it's solved by https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
      - StavrosK 7y ago
        But it's also solved by merging, which is why I don't see the point of rebasing. What's the advantage?
        cryptonector 7y ago
        Linear history.
        StavrosK 7y ago
        How is that an advantage?
        cryptonector 7y ago
        It's much easier to understand linear upstream history! Also, with this script you get to see which of your commits is conflicting with which upstream commits. That's really important information to me.
        StavrosK 7y ago
        I'll give it a shot next time I have conflicts, thanks.
        cryptonector 7y ago
        You're welcome. Leave a comment on the gist about how it goes, if you remember! I'd really like git to have this feature built-in to it...
    - 7y ago
  - cryptonector 7y ago
    https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
  - matthewbauer 7y ago
    Git rerere can help with multiple identical conflicts.
- rabidrat 7y ago
  Git was first released in 2005. Did other VCS/SCMs have a rebase workflow before git?
  - marktangotango 7y ago
    I was on a team that “merged forward” from base branches in subversion back then. What I learned later was that was one of the few teams that was a actually doing that in svn.
  - cryptonector 7y ago
    Yes. Teamware with Casper Dik's "turbo" extensions. We used that at Sun, with a rebase workflow going back much earlier than 2002, but 2002 is when I joined Sun.
    - cryptonector 7y ago
      Recall that "rebase" == identify the end of the linear history in common between this branch and the upstream, call that the merge base, identify local commits between that merge base and the head of this branch, checkout the upstream head, and cherry-pick (sequentially apply) those commits as if de novo (possibly recording this action in new metadata). One can implement that even with Fossil or any other VCS that pretends it does not implement rebase and pretends it never will.
- j1elo 7y ago
  Do you have a tool to assist with such rebase? Or something to read? I also prefer linear history without so much superfluous merge metadata, so I'd like to learn more on this.
  - cryptonector 7y ago
    https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650... (Viktor here is https://github.com/vdukhovni/ https://github.com/vdukhovni/, and I did heavily alter that code.)
    - j1elo 7y ago
      It's amazing how I'd consider myself as having a pretty good grasp of Bash programming, certainly more than average among my colleages, and still this code got me already in the second line :-) (never used typeset before) Thanks for the gist

cryptonector 7y ago

I've yet ever to see a rebase workflow fail, and I've been using a rebase workflow since at least 2002. I do sometimes have to rebase across thousands of commits because I let a branch rot, and that can be hard to rebase, but it can be equally difficult to merge. Instead I use a bisecting rebase approach where I try to rebase straight to the new upstream, and if there's conflicts, abort the rebase and try rebasing to halfway to the new upstream, continuing the process until the rebase was across just one commit, thus I can resolve conflicts directly with the upstream commit that caused them, then restart the process until done.

StavrosK 7y ago
Hmm, that doesn't match my experience. If I remember correctly, I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again. Merging doesn't have that problem, it usually just merges fine unless there are conficts in the latest commit (not all previous ones).
- philsnow 7y ago
  > I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again. is this solved by enabling git-rerere ? https://medium.com/@porteneuve/fix-conflicts-only-once-with-git-rerere-7d116b2cec67 https://medium.com/@porteneuve/fix-conflicts-only-once-with-...
  - cryptonector 7y ago
    No, it's solved by https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
    - StavrosK 7y ago
      But it's also solved by merging, which is why I don't see the point of rebasing. What's the advantage?
      - cryptonector 7y ago
        Linear history.
        StavrosK 7y ago
        How is that an advantage?
        cryptonector 7y ago
        It's much easier to understand linear upstream history! Also, with this script you get to see which of your commits is conflicting with which upstream commits. That's really important information to me.
        StavrosK 7y ago
        I'll give it a shot next time I have conflicts, thanks.
        cryptonector 7y ago
        You're welcome. Leave a comment on the gist about how it goes, if you remember! I'd really like git to have this feature built-in to it...
  - 7y ago
- cryptonector 7y ago
  https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
- matthewbauer 7y ago
  Git rerere can help with multiple identical conflicts.
rabidrat 7y ago
Git was first released in 2005. Did other VCS/SCMs have a rebase workflow before git?
- marktangotango 7y ago
  I was on a team that “merged forward” from base branches in subversion back then. What I learned later was that was one of the few teams that was a actually doing that in svn.
- cryptonector 7y ago
  Yes. Teamware with Casper Dik's "turbo" extensions. We used that at Sun, with a rebase workflow going back much earlier than 2002, but 2002 is when I joined Sun.
  - cryptonector 7y ago
    Recall that "rebase" == identify the end of the linear history in common between this branch and the upstream, call that the merge base, identify local commits between that merge base and the head of this branch, checkout the upstream head, and cherry-pick (sequentially apply) those commits as if de novo (possibly recording this action in new metadata). One can implement that even with Fossil or any other VCS that pretends it does not implement rebase and pretends it never will.
j1elo 7y ago
Do you have a tool to assist with such rebase? Or something to read? I also prefer linear history without so much superfluous merge metadata, so I'd like to learn more on this.
- cryptonector 7y ago
  https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650... (Viktor here is https://github.com/vdukhovni/ https://github.com/vdukhovni/, and I did heavily alter that code.)
  - j1elo 7y ago
    It's amazing how I'd consider myself as having a pretty good grasp of Bash programming, certainly more than average among my colleages, and still this code got me already in the second line :-) (never used typeset before) Thanks for the gist