3 ms·

How many developers contribute to a given repository using this model? A problem we have with rebasing is that developers wanting their code merged are constant

by umvi 8y ago

How many developers contribute to a given repository using this model? A problem we have with rebasing is that developers wanting their code merged are constantly having to start CI pipelines over because they had to rebase because another developer's code merged into master before theirs.

cryptonector 8y ago
At Sun, just in Solaris engineering it was over 2,000 during the 8 years I was there. For large projects, the upstream would get closed for a few hours (or days, even, like when SMF and ZFS integrated) so that tests could all pass without getting reset. Optimizing CI/CD is still important for the smaller pushes. A merge workflow doesn't really prevent pushes the get in ahead of yours from resetting the testing of yours, so anyways, I think the CI/CD thing is orthogonal to merge vs linear history.
- umvi 8y ago
  So were developers constantly having to rebase their feature branches trying to race them into master before another developer merged? How did you solve that problem?
  - cryptonector 8y ago
    I edited my comment to respond to that.
  - deleted 8y ago
    [deleted]
  - rurban 8y ago
    git rerere and mostly automatic rebasing. very rarely there are conflicts.
  - cryptonector 8y ago
    Regarding conflicts, I don't see how merge vs rebase makes a difference. If some other change sneaks in before yours and causes conflicts, well, you'll have to fix them -- rebase or merge makes no difference. Incidentally, I have a script for rebasing a branch across thousands of commits that "bisects" so that for any conflicts you're always rebasing across one commit. I.e., first it tries to rebase across all upstream commits, and if there's no conflicts, it's done, else it picks the N/2'th commit to rebase onto, and repeats, then when it's it restarts from whichever commit it ended up at.
  - Joky 8y ago
    Parent should clarify, but I doubt they were actually using git (Sun is quite old, and comment said "for decades", git isn't that old). In other VCS systems than git, you don't have the same "immutability" issue which means a "push" can be (for example) just sending a "diff" to apply to the server.
    - cryptonector 8y ago
      We used Teamware, then Mercurial. Always in a rebase workflow, at least from 1992 onward IIRC (I was there from late 2002 through one year past the completion of the Oracle acquisition).
chrisseaton 8y ago
> are constantly having to start CI pipelines Presumably the tooling does this automatically though? They're not literally have to start CI pipelines themselves?
- umvi 8y ago
  Correct, the pipeline is automatically restart, but it takes a good 5 minutes to run to completion in which time another developer might sneak in a merge and the cycle continues.
  - cryptonector 8y ago
    Merge or rebase is orthogonal to CI/CD.
    - umvi 8y ago
      Our policy is that code can't merge until CI passes. If you rebase, you have to restart CI. If another developer merges, you have to rebase. As a result I sometimes get stuck in a cycle where I'm not fast enough on the trigger and it's difficult to get my code merged because while I am waiting for CI to pass, someone else merges and I get to rebase and start CI over.
      - chrisseaton 8y ago
        Right, but how's that different between a rebase and a merge commit? In both cases, new commits appear and you need to re-run to get your commit (merge or rebased) in on top of them.
      - cryptonector 8y ago
        When you merge you still need to restart the CI. You're taking a shortcut if you have a head that passed CI, do a merge w/ no conflicts and push without redoing the CI. EDIT: And you can totally take that same shortcut with rebase. Yes, with rebase you've lost the metadata about the previous head, but you can actually keep it by including a merge commit whose only purpose is to record the previous head of your branch (you can strip these out at push time, or keep them if you like, but they will essentially be useless -- at Sun we called merge commits "turds"). Merge-vs-rebase is totally orthogonal to CI/CD, but if you find that "merging means not restarting the CI" then you've already got a bias in favor of merging in your policies and tooling, and that's why you have that perception. I would challenge you to understand how your CI/CD is forcing a merge workflow rather than merely accepting it unquestioningly.

by umvi 8y ago

cryptonector 8y ago

At Sun, just in Solaris engineering it was over 2,000 during the 8 years I was there. For large projects, the upstream would get closed for a few hours (or days, even, like when SMF and ZFS integrated) so that tests could all pass without getting reset. Optimizing CI/CD is still important for the smaller pushes. A merge workflow doesn't really prevent pushes the get in ahead of yours from resetting the testing of yours, so anyways, I think the CI/CD thing is orthogonal to merge vs linear history.

umvi 8y ago
So were developers constantly having to rebase their feature branches trying to race them into master before another developer merged? How did you solve that problem?
- cryptonector 8y ago
  I edited my comment to respond to that.
- deleted 8y ago
  [deleted]
- rurban 8y ago
  git rerere and mostly automatic rebasing. very rarely there are conflicts.
- cryptonector 8y ago
  Regarding conflicts, I don't see how merge vs rebase makes a difference. If some other change sneaks in before yours and causes conflicts, well, you'll have to fix them -- rebase or merge makes no difference. Incidentally, I have a script for rebasing a branch across thousands of commits that "bisects" so that for any conflicts you're always rebasing across one commit. I.e., first it tries to rebase across all upstream commits, and if there's no conflicts, it's done, else it picks the N/2'th commit to rebase onto, and repeats, then when it's it restarts from whichever commit it ended up at.
- Joky 8y ago
  Parent should clarify, but I doubt they were actually using git (Sun is quite old, and comment said "for decades", git isn't that old). In other VCS systems than git, you don't have the same "immutability" issue which means a "push" can be (for example) just sending a "diff" to apply to the server.
  - cryptonector 8y ago
    We used Teamware, then Mercurial. Always in a rebase workflow, at least from 1992 onward IIRC (I was there from late 2002 through one year past the completion of the Oracle acquisition).

chrisseaton 8y ago

> are constantly having to start CI pipelines Presumably the tooling does this automatically though? They're not literally have to start CI pipelines themselves?

umvi 8y ago
Correct, the pipeline is automatically restart, but it takes a good 5 minutes to run to completion in which time another developer might sneak in a merge and the cycle continues.
- cryptonector 8y ago
  Merge or rebase is orthogonal to CI/CD.
  - umvi 8y ago
    Our policy is that code can't merge until CI passes. If you rebase, you have to restart CI. If another developer merges, you have to rebase. As a result I sometimes get stuck in a cycle where I'm not fast enough on the trigger and it's difficult to get my code merged because while I am waiting for CI to pass, someone else merges and I get to rebase and start CI over.
    - chrisseaton 8y ago
      Right, but how's that different between a rebase and a merge commit? In both cases, new commits appear and you need to re-run to get your commit (merge or rebased) in on top of them.
    - cryptonector 8y ago
      When you merge you still need to restart the CI. You're taking a shortcut if you have a head that passed CI, do a merge w/ no conflicts and push without redoing the CI. EDIT: And you can totally take that same shortcut with rebase. Yes, with rebase you've lost the metadata about the previous head, but you can actually keep it by including a merge commit whose only purpose is to record the previous head of your branch (you can strip these out at push time, or keep them if you like, but they will essentially be useless -- at Sun we called merge commits "turds"). Merge-vs-rebase is totally orthogonal to CI/CD, but if you find that "merging means not restarting the CI" then you've already got a bias in favor of merging in your policies and tooling, and that's why you have that perception. I would challenge you to understand how your CI/CD is forcing a merge workflow rather than merely accepting it unquestioningly.