3 ms·

I would reject a merge from a branch that does more than one thing at a time as you've described during code review. It's okay to have a branch that does a bunc

by dljsjr 5y ago

I would reject a merge from a branch that does more than one thing at a time as you've described during code review. It's okay to have a branch that does a bunch of things at the same time, but come time to merge back to `main` this should be broken up in to several different PR's. I would probably branch off my branch for each logical change I wanted merged and use `rebase -i` to wholesale drop commits that I didn't want on the branch anymore. This is also an example of where stacked diffs are far superior to PR's but that's a separate issue.

ninkendo 5y ago
Nothing in sandgiant's post implied that there's more than one thing happening in the branch. Quite the opposite actually, they said that the final diff could be much smaller than the sum of all the small WIP commits along the way. It could be that after hours of digging, you found the real bug was a typo somewhere, and the final diff may be just a 2-line change, where one of the WIP commits was rewriting the whole auth layer because you were chasing a dead-end.
- dljsjr 5y ago
  That's exactly what `git commit --fixup` and `git rebase --autosquash` does then.
  - ninkendo 5y ago
    Even with autosquash, rebasing has to iterate through each commit individually before creating the final commit. Which means it's touching a bunch of files in your working tree while that's happening, which means build tools like make now have to rebuild them because the timestamps have changed. What's worse, is if you rebase (say, 20 commits) onto a newer branch than the one you started with, and you have merge conflicts (say, on commit #10), now you might have to fix the conflicts over and over for every commit after the first conflicting one (depending on the contents of the commits). I know there's `git rerere`, but after 16 years using git I've still never learned how it works. Using reset to squash first, guarantees that you create your single commit first, without dealing with merge conflicts/etc, and then you can rebase that resulting commit once, to deal with conflicts once.

by dljsjr 5y ago

ninkendo 5y ago

Nothing in sandgiant's post implied that there's more than one thing happening in the branch. Quite the opposite actually, they said that the final diff could be much smaller than the sum of all the small WIP commits along the way. It could be that after hours of digging, you found the real bug was a typo somewhere, and the final diff may be just a 2-line change, where one of the WIP commits was rewriting the whole auth layer because you were chasing a dead-end.

dljsjr 5y ago
That's exactly what `git commit --fixup` and `git rebase --autosquash` does then.
- ninkendo 5y ago
  Even with autosquash, rebasing has to iterate through each commit individually before creating the final commit. Which means it's touching a bunch of files in your working tree while that's happening, which means build tools like make now have to rebuild them because the timestamps have changed. What's worse, is if you rebase (say, 20 commits) onto a newer branch than the one you started with, and you have merge conflicts (say, on commit #10), now you might have to fix the conflicts over and over for every commit after the first conflicting one (depending on the contents of the commits). I know there's `git rerere`, but after 16 years using git I've still never learned how it works. Using reset to squash first, guarantees that you create your single commit first, without dealing with merge conflicts/etc, and then you can rebase that resulting commit once, to deal with conflicts once.