4 ms·

Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of

Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity. What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history reflects reality - each commit has an actual state of the repo that you had on your machine. Or you can rebase, in which case all of the commits on your branch now contain code that no-one ever had on their machine, not tested, never run, maybe it doesn't compile, maybe it's nonsense. Both result in the same diff from master so are equivalent for submitting a patchset. It's really hard for me to see the value of trashing your history like that. People like linear history but history actually is not linear sometimes.

_ikke_ 3y ago
Lots of criss-cross merges make it really difficult to follow history, making it less useful. Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit. In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many persons put all the burden on the receiving side.
- gcarvalho 3y ago
  > After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit You can push directly to the target branch. git push origin my-branch:master If your branch is a direct continuation of master -- which is often the desired result of rebasing -- then no merge and no force-push are necessary. (I'm not saying this is a good workflow, btw.)
  - _ikke_ 3y ago
    Which is the equivalent of a fast-forward merge. Same result, different mechanism.

_ikke_ 3y ago

Lots of criss-cross merges make it really difficult to follow history, making it less useful. Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit. In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many persons put all the burden on the receiving side.

gcarvalho 3y ago
> After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit You can push directly to the target branch. git push origin my-branch:master If your branch is a direct continuation of master -- which is often the desired result of rebasing -- then no merge and no force-push are necessary. (I'm not saying this is a good workflow, btw.)
- _ikke_ 3y ago
  Which is the equivalent of a fast-forward merge. Same result, different mechanism.