Johan Herland writes: >On Tuesday 26 January 2010, Aaron Crane wrote: >> One thing to be aware of (beyond the need to run grep to convert old >> CVS revision numbers to Git commit IDs) which sounds like a job for a small tool, maybe aliased in .git/config. 'git cvsinfo file.c 1.23' or 'git cvsinfo [file.c] <git-commitname>' --> output cvs and git commit info (cvs rev, commit, log message, etc). Or maybe it shouldn't be cvs-specific. >> is that there's a good chance >> the mapping file will pollute the results of `git grep` for some >> tasks. (We've put the mapping file into our repo, where it's easy to >> find.) I'm considering gzipping the mapping file as a workaround; >> that would mean our users will need to use zgrep (or equivalent) to >> look up CVS revision numbers, which may or may not be a problem in >> your situation. Thanks for the tip. Zipping sounds good. In particular combined with the grepping tool above. If the unzipping gets slow, cvsinfo --unpack could always put a bunzipped file in .git/cvsinfo.txt or something. > You could consider adding the CVS revision numbers as notes (see "git help > notes" in >= v1.6.6) to the corresponding commits. Then they don't pollute > the commit messages, but instead live in a separate, but parallel hierarchy > that can be easily pulled in when you need to reference them (e.g. > GIT_NOTES_REF="refs/" git log). Thanks, looks better than munging the log. Though with one common weakness - should likely omit noting mass commits, since they'd clutter what 'git log' displays too much. Of course, either could used combined with a mapping table. -- Hallvard -- 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