> > That means it is not in general possible to tell which branch a particular commit belongs to.
>
>That's because commits can belong to multiple branches, which is by design.
I could be wrong, but I think what they mean is the fact that once you merge/rebase your dev branch back into master, all of those commits you made in dev are now commits in master.
You could conceivably have a source control system that still allows commits to belong to multiple branches, but bakes the branches of a commit into the commit. (And I believe many/most other source control systems do just that.)
The fact that the branches of a commit can change later on always struck me as being completely inconsistent with the commonly held idea about git that outside of master it's ok to forego testing. That really only works if you squash into master (and test that squash commit). If you don't squash, and especially if you fast-forward, then all of those commits are now "in" master, and so you've dumped a bunch of untested stuff in master.
That's because commits can belong to multiple branches, which is by design.
> Therefore visualizing complicated branching scenarios, in ways that makes sense to users, becomes almost impossible.
There a reason users need to visualize complicated branch scenarios?
> This is why people advocate rebasing https://blog.carbonfive.com/2017/08/28/always-squash-and-reb.... The idea is to "lie" to the vcs because otherwise your history becomes a hodge-podge mess of merges. :)
Rebasing/cherry-picking isn't lying, it's avoiding the mess of a merge at the expense of being a tad more difficult.
Seems you have a very concrete idea of what you think a VCS is, and git disagrees with you, thus they "all suck".