3 ms·

I hate rebases because they create multiple hashes for the same logical commit. It confuses the crap out of me sometimes. Also, they tend to involve more manual

I hate rebases because they create multiple hashes for the same logical commit. It confuses the crap out of me sometimes. Also, they tend to involve more manual processing, and thus human error, then merges.

u801e 7y ago
> I hate rebases because they create multiple hashes for the same logical commit Some of those commits may have changed (either the commit message or the diff itself). There's a git command called range-diff[1] that was added recently that allows you to diff between rebases. > Also, they tend to involve more manual processing, and thus human error, then merges. Before actually pushing up the rebased branch, you run a diff against the upstream tracking branch to see if any inadvertent changes were introduced. For example: git diff @{u}.. And use the range-diff command to see the difference between the upstream tracking branch and your locally rebased branch. [1] https://git-scm.com/docs/git-range-diff https://git-scm.com/docs/git-range-diff
jmvoodoo 7y ago
This. I've had to spend time fixing history after a Jr engineer did a bad rebase. After a few episodes of that I decided I had to either stop hiring Jr engineers, have them always supervised by a Sr engineer, or stop rebasing. I stopped rebasing.
- u801e 7y ago
  > I've had to spend time fixing history after a Jr engineer did a bad rebase. I tell people to run git log -p --reverse origin/master.. on the rebased branch and check that everything works before they push up their branch to the remote. I also tell them to run git rebase --exec "linting-command" --exec "unit-test-command" --exec "integration-test-command" and make sure that tests pass for every single commit. If they don't, then they spend time fixing it until they do.
- Buttons840 7y ago
  You'd be better off blaming the force push rather than the rebase. A rebase I do on my computer will not affect you unless I force push. I think it's completely reasonable to ask all developers to get a second opinion before force pushing.

u801e 7y ago

> I hate rebases because they create multiple hashes for the same logical commit Some of those commits may have changed (either the commit message or the diff itself). There's a git command called range-diff[1] that was added recently that allows you to diff between rebases. > Also, they tend to involve more manual processing, and thus human error, then merges. Before actually pushing up the rebased branch, you run a diff against the upstream tracking branch to see if any inadvertent changes were introduced. For example: git diff @{u}.. And use the range-diff command to see the difference between the upstream tracking branch and your locally rebased branch. [1] https://git-scm.com/docs/git-range-diff https://git-scm.com/docs/git-range-diff

jmvoodoo 7y ago

This. I've had to spend time fixing history after a Jr engineer did a bad rebase. After a few episodes of that I decided I had to either stop hiring Jr engineers, have them always supervised by a Sr engineer, or stop rebasing. I stopped rebasing.

u801e 7y ago
> I've had to spend time fixing history after a Jr engineer did a bad rebase. I tell people to run git log -p --reverse origin/master.. on the rebased branch and check that everything works before they push up their branch to the remote. I also tell them to run git rebase --exec "linting-command" --exec "unit-test-command" --exec "integration-test-command" and make sure that tests pass for every single commit. If they don't, then they spend time fixing it until they do.
Buttons840 7y ago
You'd be better off blaming the force push rather than the rebase. A rebase I do on my computer will not affect you unless I force push. I think it's completely reasonable to ask all developers to get a second opinion before force pushing.