retitle 493646 git cvsimport -m: too eager to declare a merge
reassign 493646 git-cvs
thanks
Kurt Roeckx wrote:
> I think they're mostly created using git cvsimport, which seems
> to be doing something else and makes it show up as a merge.
Okay, so the problem is that merges in the CVS world and git world are
completely different things, but git cvsimport is pretending that they
are not. Here’s what the merge detection code (which is very old:
v0.99.5~15^2~6, 2005-08-16) says:
[PATCH] Add merge detection to git-cvsimport
Added -m and -M flags for git-cvsimport to detect merge
commits in cvs. While this trusts the commit message, in
repositories where merge commits indicate 'merged from
FOOBRANCH' the import works surprisingly well.
Even if some merges from CVS are bogus or incomplete, the
resulting branches are in better state to go forward (and
merge) than without any merge detection.
It detects merges by looking at the commit message and is not smart
enough to tell when this was just a backport of a few patches from a
branch.
I do not know how much information CVS actually records about a merge.
Is the information you want available in CVS? Can it be determined
locally (from looking at ,v files) or remotely (with cvs log or rlog)?
> So to keep with my example, H was a bugfix for F, so you would:
> git cherry-pick -x F
> git cherry-pick -x H
>
> But that's clearly not the behaviour I was seeing, and that looks
> obvious what the history is. It also does not indicate any "merge".
Right. Thanks for your explanations --- they have been very helpful.
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100215061717.gc22...@progeny.tock
