I used git-cvsimport -k to create my own git repo to deal with a
project that uses CVS. I push my mods upstream using
git-cvsexportcommit. This works fine *unless* there is a keyword
mismatch, i.e., some file in git has $Id: foo$ while in CVS keyword
expansion somehow changed it to $Id: bar$. In that case
git-cvsexportcommit barfs with a patch failure.
When that happens I use git-format-patch to generate a patch file and
integrate it manually. BLECH! This also confuses git-cvsimport when
I try to pull upstream changes, so I end up manually resolving the
keyword conflict again at that point, i.e., twice.
Simply avoiding expanded keywords should solve the problem. I thought
git-cvsimport -k would keep them out of my git repo, but no such luck.
Even when I use "cvs checkout -kk" for the CVS sandbox and then
"git-cvsimport -k", keywords were *still* expanded in my git repo.
(This is with both git 1.4.4.4 and git 1.5.6.) Either the -k switch
to git-cvsimport is busted, or I'm doing something wrong. In any case
even if this approached worked it would introduce a host of new
issues, since others on the project *are* using keyword expansion, and
the build process relies upon them.
One solution that occurs to me would be for git-cvsexportcommit to do
the dirty work of ignoring keyword mismatches for files that do not
have keywords disabled in CVS. It seems like it is in the best
position to solve the problem---everything else is hacking around to
avoid it instead of actually solving it, which gets brittle. So what
I'm hoping is that this lengthy discourse of mine will convince
someone to add code to git-cvsexportcommit that causes the patch
creation and application stuff inside it to ignore keyword expansion
mismatches (on files which do not have -kb on in CVS), perhaps by
simply contracting keywords on all files/patches from both CVS/git at
an early stage.
The same hack could be used in git-cvsimport to avoid the same problem
in the other direction, albeit with a little mo...
