4 ms·

That's fine of course. Personally, I prefer to make things as easy as possible to understand at that unspecified but probable future date when a customer opens

by idop 4y ago

That's fine of course. Personally, I prefer to make things as easy as possible to understand at that unspecified but probable future date when a customer opens a SEV1 and I have to consult with the log, among other things. Make it idiot proof later, when time is _really_ of the essence, rather than now, when you're being artificially pressured to deliver that story for the sprint review in two hours.

Jenk 4y ago
I'm advocating that merge commits in main make it easier precisely for the requirements you specify: To track what feature(s) was introduced at a given release. With merge commits you not only have groupings of commits for features developed, you have that ability to revert a whole feature with just one revert. If you rebase onto main you are flattening those groupings and the entire commit stack into one serial history. For super quick "fix forward" products, that's fine and I would be happy with that. In products that are not so quick or perhaps you have tighter controls/SLAs/etc. Being able to immediately identify and revert an entire feature from main is very valuable, above and beyond a feature toggle imho.
- pierrebai 4y ago
  Squash commit will squash everything done into a single commit, so reverting it is easier. Also when you have to cherry-pick fixes into an older release branch, you get to fully appreciate squashed merges. If you did not squash, you need to cherry-pick all commits from the merge. If the feature branch was not rebased and the dev merged main into the feature branch multiple times, then the branch commits are inter-mingled with main commits and it is so easy to mess up the cherry-picking. Just imagine if the dev had to fix conflicts... All that makes squash commit a time-saver.
  - tremon 4y ago
    so reverting it is easier. Only reverting the entire feature is easier. Reverting a single change (for example, because it introduced a bug but is not critical to the feature itself) becomes much harder after squash.
  - seba_dos1 4y ago
    > Squash commit will squash everything done into a single commit, so reverting it is easier. No, it's just as easy, while needlessly throwing away other useful information. > If you did not squash, you need to cherry-pick all commits from the merge. ...or use a single `git rebase` invocation. > If the feature branch was not rebased Linear workflows with merge commits usually require feature branches to be rebased on merge (just like squashes, just without the actual squashing), so that's not a problem at all.

by idop 4y ago

Jenk 4y ago

I'm advocating that merge commits in main make it easier precisely for the requirements you specify: To track what feature(s) was introduced at a given release. With merge commits you not only have groupings of commits for features developed, you have that ability to revert a whole feature with just one revert. If you rebase onto main you are flattening those groupings and the entire commit stack into one serial history. For super quick "fix forward" products, that's fine and I would be happy with that. In products that are not so quick or perhaps you have tighter controls/SLAs/etc. Being able to immediately identify and revert an entire feature from main is very valuable, above and beyond a feature toggle imho.

pierrebai 4y ago
Squash commit will squash everything done into a single commit, so reverting it is easier. Also when you have to cherry-pick fixes into an older release branch, you get to fully appreciate squashed merges. If you did not squash, you need to cherry-pick all commits from the merge. If the feature branch was not rebased and the dev merged main into the feature branch multiple times, then the branch commits are inter-mingled with main commits and it is so easy to mess up the cherry-picking. Just imagine if the dev had to fix conflicts... All that makes squash commit a time-saver.
- tremon 4y ago
  so reverting it is easier. Only reverting the entire feature is easier. Reverting a single change (for example, because it introduced a bug but is not critical to the feature itself) becomes much harder after squash.
- seba_dos1 4y ago
  > Squash commit will squash everything done into a single commit, so reverting it is easier. No, it's just as easy, while needlessly throwing away other useful information. > If you did not squash, you need to cherry-pick all commits from the merge. ...or use a single `git rebase` invocation. > If the feature branch was not rebased Linear workflows with merge commits usually require feature branches to be rebased on merge (just like squashes, just without the actual squashing), so that's not a problem at all.