Re: Slightly off topic, question about git

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 8 Jun 2022 22:22:40 +0200
> From: Reinoud Zandijk <reinoud%NetBSD.org@localhost>
> 
> 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.)