> Date: Wed, 8 Jun 2022 22:22:40 +0200 > From: Reinoud Zandijk <rein...@netbsd.org> > > My (little) experience with git is that merging ie applying patches > from others is a lot better in CVS! I never really have merge > conflicts in CVS but in the project I used git on it was horrible > for no obvious reasons so I switched to rebase since that just > worked fine. But then I might have missed some `magic' git > incantation *grumbl*
If you have an actual scenario where applying patches appears to be more difficult in git than in cvs, let me know and I can help with that. Note that a cvs merge (that is, cvs update -j -j) is more or less squashing the branch and then rebasing it. git merge, in contrast, formally records the history with a pointer to both parents of the merge -- this can be confusing when nearly every commit to a shared repository that many people are working on is a merge commit with a complicated branching DAG structure. It is more likely that the branching DAG structure has led to confusion -- and, perhaps, the same commit appearing with multiple identities on different branches -- than that you have actual merge conflicts. The cvs merge algorithm is essentially a special case of the git merge algorithm, restricted to a simpler history structure than the general structures git supports; if cvs has no trouble with a merge then git is unlikely to have trouble with it. (hg has a better way to track the same commit appearing with multiple identities on different branches over rebases, with hg-evolve (devel/py-hg-evolve), so one tends not to run into this kind of thing as much with hg.)