3 ms·

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 day

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).

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).