Nick Woolley venit, vidit, dixit 25.11.2009 12:59:
> Hi,
>
> I have a git repository with a merge point on the master branch. This merge
> commit is empty, and just contains a commit message:
>
> Merge commit 'otherbranch'
>
> I'm trying to export this branch into CVS using git-cvsexportcommit (the latest
> version from the master branch). It's actually done in a wrapper script [1] but
> the command that gets invoked is essentially:
>
> git cvsexportcommit -p -v -u -w 'cvscheckout/HEAD/my-cvs-module' -c \
> <parent commit> <commit>
>
> Where <commit> is the empty merge commit. However this invocation dies and
> aborts the process of exporting the branch half way.
>
> The fatal error I get is:
>
> Applying to CVS commit <commit> from parent <parent commit>
> Checking if patch will apply
> Applying
> error: No changes
> cannot patch at /usr/lib/git-core/git-cvsexportcommit line 324.
>
> The vicinity of line 324 is (with some lines wrapped):
>
> print "Applying\n";
> if ($opt_W) {
> system("git checkout -q $commit^0") && die "cannot patch";
> } else {
> `GIT_DIR= git-apply $context --summary --numstat --apply
> <.cvsexportcommit.diff` || die "cannot patch";
> }
>
> It seems that the file .cvsexportcommit.diff is empty, so git-apply is refusing
> to apply it.
>
> Presumably the application would be a no-op, so this git-apply step could be
> skipped. So I tried modifying the script to do that and it seems to work:
>
> print "Applying\n";
> if ($opt_W) {
> system("git checkout -q $commit^0") && die "cannot patch";
> } elsif (-s ".cvsexportcommit.diff") {
> `GIT_DIR= git-apply $context --summary --numstat --apply
> <.cvsexportcommit.diff` || die "cannot patch";
> } else {
> print "No changes\n";
> }
>
> The modified git-cvsexportcommit script completes without errors, but
> unsurprisingly, seems to export nothing, so that when imported back into git,
> there is no empty commit. There appears to be no log message added in CVS, either.
>
> This does seem more acceptable than dying, although it doesn't faithfully
> reproduce the git history. However I'm not sure if that would be possible in
> this case.
>
> Is the existing behaviour deliberately fatal, or is this worth supplying a patch
> for?
I think the behavior is correct in the sense that you're telling git
cvsexportcommit to make a commit to cvs, and it can't, because there is
no change to commit. A merge can't be represented.
It leaves you the choice between omitting the trivial merge from cvs
history (that's what one would do for a merge based cvs<->git workflow)
and generating a fake commit in cvs. I don't know if it has something
like --allow-empty - it's file base, after all.
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html