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 more work since keywords that were not unexpanded in the git files would need to be re-expanded in git to avoid gratuitous keyword-value-change patches.
Or perhaps I'm missing some other solution...? -- Barak A. Pearlmutter Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/
