5 ms·

Rebase is great, but it's usefulness really depends on the commit history. If your branch consists of 10 commits of trying various things, then the sum of chan

Rebase is great, but it's usefulness really depends on the commit history. If your branch consists of 10 commits of trying various things, then the sum of changes in all the commits can easily become significantly larger than the final branch diff. In that case resetting is orders of magnitudes faster than fiddling with rebase.

okl 5y ago
> If your branch consists of 10 commits of trying various things Use fixup commits.
GauntletWizard 5y ago
That's the point of squashing commits - Many of your changes will ultimately pare down into just a few logical thoughts, adding function X to feature A, then using that in function Y in feature B etc... It's not something that comes for free, of course, but if you make many small commits and try to get each file to compile each time you can often basically just squash by file or directory.
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.

okl 5y ago

> If your branch consists of 10 commits of trying various things Use fixup commits.

GauntletWizard 5y ago

That's the point of squashing commits - Many of your changes will ultimately pare down into just a few logical thoughts, adding function X to feature A, then using that in function Y in feature B etc... It's not something that comes for free, of course, but if you make many small commits and try to get each file to compile each time you can often basically just squash by file or directory.

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.