{"thread":{"id":"22399","subject":"cvs revision number -> git commit name?","startedAt":"2010-01-26T21:53:12Z","lastAt":"2010-01-27T22:19:30Z","messageCount":7,"participants":["Hallvard B Furuseth","Aaron Crane","Johan Herland","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"132718","messageId":"hbf.20100126bda0@bombur.uio.no","threadId":"22399","inReplyTo":null,"subject":"cvs revision number -> git commit name?","fromName":"Hallvard B Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2010-01-26T21:53:12Z","receivedAt":"2010-01-26T21:53:12Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":"When moving from CVS to Git, what's a good way to help Git users\nfind an old commit given the original CVS revision number? Are\nthere tools available to help?\n\nThere are plenty of still-useful references to CVS revisions\nfloating around - in bug reports, mailing list archives, commit\nmessages referring to other commits. Some loose thoughts:\n\nOne could commit a table with a (file,revision)->commit mapping,\nI suppose something can generate it when importing from cvs?\n\nMany but far from all old file contain the CVS ID, named $OpenLDAP$.\nCan Git grep all versions of a file for '\\$OpenLDAP:.* 1.23 '?\n\nCould maybe add a line like this to many of the log messages:\n \"\"\nfor single-file commits, or\n \"\"\nfor multi-file comments with few enough files that such an\nannotation fits on one line. That'll make log messages like \"fix\nrev 1.23\" easier to read without need for a tool to find what the\nmessage is talking about, but does clutter up the log a lot.\n\nSome stats:\n 1600 files = 23M text, 770k lines, in 100 directories.\n Maybe 20000 Git commits, 50M ldap.git/.git/ directory.\n\n-- \nHallvard\n"},{"id":"132722","messageId":"bc341e101001261453u16124186i298a53ead0b4eee2@mail.gmail.com","threadId":"22399","inReplyTo":"hbf.20100126bda0@bombur.uio.no","subject":"Re: cvs revision number -> git commit name?","fromName":"Aaron Crane","fromEmail":"git@aaroncrane.co.uk","sentAt":"2010-01-26T22:53:15Z","receivedAt":"2010-01-26T22:53:15Z","isPatch":false,"sender":{"key":"git@aaroncrane.co.uk","avatar":null},"body":"Hallvard B Furuseth wrote:\n> When moving from CVS to Git, what's a good way to help Git users\n> find an old commit given the original CVS revision number?  Are\n> there tools available to help?\n>\n> One could commit a table with a (file,revision)->commit mapping,\n> I suppose something can generate it when importing from cvs?\n\nThat's what we decided to do on a recent CVS-to-Git conversion, though\nlike you, we also considered munging the log messages instead. Our\njury's still out on whether it was the right decision; we haven't had\nmuch cause to use the result yet.\n\nOne thing to be aware of (beyond the need to run grep to convert old\nCVS revision numbers to Git commit IDs) is that there's a good chance\nthe mapping file will pollute the results of `git grep` for some\ntasks. (We've put the mapping file into our repo, where it's easy to\nfind.) I'm considering gzipping the mapping file as a workaround;\nthat would mean our users will need to use zgrep (or equivalent) to\nlook up CVS revision numbers, which may or may not be a problem in\nyour situation.\n\nI have an initial patch to git-cvsimport that adds a switch to\ngenerate the mapping as it goes. I'm currently trying to find time to\nclean it up and submit it.\n\n-- \nAaron Crane ** http://aaroncrane.co.uk/\n"},{"id":"132728","messageId":"201001270043.44614.johan@herland.net","threadId":"22399","inReplyTo":"bc341e101001261453u16124186i298a53ead0b4eee2@mail.gmail.com","subject":"Re: cvs revision number -> git commit name?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-01-26T23:43:44Z","receivedAt":"2010-01-26T23:43:44Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 26 January 2010, Aaron Crane wrote:\n> Hallvard B Furuseth wrote:\n> > When moving from CVS to Git, what's a good way to help Git users\n> > find an old commit given the original CVS revision number? Are\n> > there tools available to help?\n> >\n> > One could commit a table with a (file,revision)->commit mapping,\n> > I suppose something can generate it when importing from cvs?\n> \n> That's what we decided to do on a recent CVS-to-Git conversion, though\n> like you, we also considered munging the log messages instead. Our\n> jury's still out on whether it was the right decision; we haven't had\n> much cause to use the result yet.\n> \n> One thing to be aware of (beyond the need to run grep to convert old\n> CVS revision numbers to Git commit IDs) is that there's a good chance\n> the mapping file will pollute the results of `git grep` for some\n> tasks. (We've put the mapping file into our repo, where it's easy to\n> find.) I'm considering gzipping the mapping file as a workaround;\n> that would mean our users will need to use zgrep (or equivalent) to\n> look up CVS revision numbers, which may or may not be a problem in\n> your situation.\n> \n> I have an initial patch to git-cvsimport that adds a switch to\n> generate the mapping as it goes. I'm currently trying to find time to\n> clean it up and submit it.\n\nYou could consider adding the CVS revision numbers as notes (see \"git help \nnotes\" in >= v1.6.6) to the corresponding commits. Then they don't pollute \nthe commit messages, but instead live in a separate, but parallel hierarchy \nthat can be easily pulled in when you need to reference them (e.g. \nGIT_NOTES_REF=\"refs/\" git log).\n\nThe notes feature is still very new, and there are still outstanding patches \nto be merged, but the basics are there in v1.6.6.\n\nFWIW, I was also working on a CVS-to-Git importer (based on what has later \nbecome the transport-helper infrastructure), that used notes to store \nexactly the metadata you mention above. However, I haven't worked on it for \na while, and I probably won't have time to pick it up in the immediate \nfuture.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"132755","messageId":"7vpr4wq6w3.fsf@alter.siamese.dyndns.org","threadId":"22399","inReplyTo":"201001270043.44614.johan@herland.net","subject":"Re: cvs revision number -> git commit name?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-27T08:38:52Z","receivedAt":"2010-01-27T08:38:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> The notes feature is still very new, and there are still outstanding patches \n> to be merged, but the basics are there in v1.6.6.\n\nBy the way, we should seriously rethink how notes should propagate through\nrebases and amends. I've been using this in my post-applypatch hook\nlately:\n\n-- >8 -- cut here -- >8 --\n#!/bin/sh\nGIT_DIR=.git\ndotest=\"$GIT_DIR/rebase-apply\"\n\nprec=4 &&\nthis=$(cat 2>/dev/null \"$dotest/next\") &&\nmsgnum=$(printf \"%0${prec}d\" $this) &&\ntest -f \"$dotest/$msgnum\" &&\nmessage_id=$(sed -n '\n\t/^Message-I[Dd]:[ \t]*\\(<.*>\\)[ \t]*$/{\n\t\ts//\\1/p\n\t\tq\n\t}\n\t/^$/q\n' \"$dotest/$msgnum\") &&\ntest -n \"$message_id\" &&\nGIT_NOTES_REF=refs/notes/amlog \\\n\tgit notes edit -m \"Message-Id: $message_id\" HEAD\n-- 8< -- upto here -- 8< --\n\ntogether with this in $HOME/.gitconfig\n\n-- >8 -- cut here -- >8 --\n[alias]\n\tlgm = \"!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \\\"$@\\\" || :' -\"\n-- 8< -- upto here -- 8< --\n\nso that I can say:\n\n\t$ git lgm -1 jh/maint-config-file-prefix\n commit 65807ee697a28cb30b8ad38ebb8b84cebd3f255d\n Author: Johan Herland \n Date: Tue Jan 26 16:02:16 2010 +0100\n\n builtin-config: Fix crash when using \"-f \" from non-root dir\n\n When your current directory is not ...\n\t ...\n\n Notes:\n Message-Id: <201001261602.16876.johan@herland.net>\n\nA few observations I made myself so far:\n\n - I used to fix minor issues (styles, decl-after-stmt, etc.) using\n rebase-i long after running \"am\" in bulk, but these days I find myself\n going back to my \"inbox\" and fix them in MUA; this is only because I\n know these notes do not propagate across rebases and amends---adjusting\n the workflow to the tool's limitation is not very good.\n\n - The interface to tell tools to use which notes ref to use should be\n able to say \"these refs\", not just \"this ref\" i.e. GIT_NOTES_REF=a:b\n just like PATH=a:b:c...); I am fairly certain that we would want to\n store different kind of information in separate notes trees and\n aggregate them, as we gain experience with notes.\n\n - There should be an interface to tell tools to use which notes refs via\n command line options; \"!alias\" does not TAB-complete, and \"git lgm\"\n above doesn't, either. \"git log --notes=notes/amlog --notes=notes/other\"\n would probably be the way to go.\n\n - While reviewing the \"inbox\", I sometimes wonder if I applied a message\n to somewhere already, but there is no obvious way to grep in the notes\n tree and get the object name that a note is attached to. Of course I\n know I can \"git grep -c johan@herland.net notes/amlog\" and it will give\n me something like:\n\n notes/amlog:65807ee697a28cb30b8ad38ebb8b84cebd3f255d:1\n notes/amlog:c789176020d6a008821e01af8b65f28abc138d4b:1\n\n but this won't scale and needs scripting to mechanize, once we start\n rebalancing the notes tree with different fan-outs. The end user (me\n in this case) is interested in \"set of objects that match this grep\n criteria\", not \"the pathnames the notes tree's implementation happens\n to use to store notes for them in the hierarchy\".\n"},{"id":"132767","messageId":"201001271228.50992.johan@herland.net","threadId":"22399","inReplyTo":"7vpr4wq6w3.fsf@alter.siamese.dyndns.org","subject":"Re: git notes issues (was: cvs revision number -> git commit name?)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-01-27T11:28:50Z","receivedAt":"2010-01-27T11:28:50Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 27 January 2010, Junio C Hamano wrote:\n> Johan Herland writes:\n> > The notes feature is still very new, and there are still outstanding\n> > patches to be merged, but the basics are there in v1.6.6.\n> \n> By the way, we should seriously rethink how notes should propagate\n> through rebases and amends. I've been using this in my post-applypatch\n> hook lately:\n> \n> [...]\n> \n> A few observations I made myself so far:\n> \n> - I used to fix minor issues (styles, decl-after-stmt, etc.) using\n> rebase-i long after running \"am\" in bulk, but these days I find myself\n> going back to my \"inbox\" and fix them in MUA; this is only because I\n> know these notes do not propagate across rebases and\n> amends---adjusting the workflow to the tool's limitation is not very\n> good.\n\nAgreed. I simply haven't had time to look much into this yet. We should \nprobably add options (both command-line options and config variables) to \n'git rebase', 'git commit --amend', 'git cherry-pick', etc. for bringing \nnotes across a commit rewrite. We should probably also add \"git notes \nmove/copy \" subcommands to make the same operations \navailable to scripts (and users).\n\n> - The interface to tell tools to use which notes ref to use should be\n> able to say \"these refs\", not just \"this ref\" i.e. GIT_NOTES_REF=a:b\n> just like PATH=a:b:c...); I am fairly certain that we would want to\n> store different kind of information in separate notes trees and\n> aggregate them, as we gain experience with notes.\n\nAgreed.\n\n> - There should be an interface to tell tools to use which notes refs via\n> command line options; \"!alias\" does not TAB-complete, and \"git lgm\"\n> above doesn't, either. \"git log --notes=notes/amlog\n> --notes=notes/other\" would probably be the way to go.\n\nAgreed.\n\n> - While reviewing the \"inbox\", I sometimes wonder if I applied a message\n> to somewhere already, but there is no obvious way to grep in the notes\n> tree and get the object name that a note is attached to. Of course I\n> know I can \"git grep -c johan@herland.net notes/amlog\" and it will\n> give me something like:\n> \n> notes/amlog:65807ee697a28cb30b8ad38ebb8b84cebd3f255d:1\n> notes/amlog:c789176020d6a008821e01af8b65f28abc138d4b:1\n> \n> but this won't scale and needs scripting to mechanize, once we start\n> rebalancing the notes tree with different fan-outs. The end user (me\n> in this case) is interested in \"set of objects that match this grep\n> criteria\", not \"the pathnames the notes tree's implementation happens\n> to use to store notes for them in the hierarchy\".\n\nAgreed. Should add a \"git notes grep\" subcommand.\n\nI hope that once the updated notes API is in (I'll send an update to what's \nin 'pu' shortly), people will have the tools they need to start integrating \nnotes with their pet Git features. As you illustrate perfectly above, there \nare many corners to be smoothed out before this is well integrated with the \nother Git tools.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"132815","messageId":"hbf.20100127jjbx@bombur.uio.no","threadId":"22399","inReplyTo":"201001270043.44614.johan@herland.net","subject":"Re: cvs revision number -> git commit name?","fromName":"Hallvard B Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2010-01-27T17:47:18Z","receivedAt":"2010-01-27T17:47:18Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":"Johan Herland writes:\n>On Tuesday 26 January 2010, Aaron Crane wrote:\n>> One thing to be aware of (beyond the need to run grep to convert old\n>> CVS revision numbers to Git commit IDs)\n\nwhich sounds like a job for a small tool, maybe aliased in .git/config.\n'git cvsinfo file.c 1.23' or 'git cvsinfo [file.c] ' -->\noutput cvs and git commit info (cvs rev, commit, log message, etc).\nOr maybe it shouldn't be cvs-specific.\n\n>> is that there's a good chance\n>> the mapping file will pollute the results of `git grep` for some\n>> tasks. (We've put the mapping file into our repo, where it's easy to\n>> find.) I'm considering gzipping the mapping file as a workaround;\n>> that would mean our users will need to use zgrep (or equivalent) to\n>> look up CVS revision numbers, which may or may not be a problem in\n>> your situation.\n\nThanks for the tip. Zipping sounds good. In particular combined with\nthe grepping tool above. If the unzipping gets slow, cvsinfo --unpack\ncould always put a bunzipped file in .git/cvsinfo.txt or something.\n\n> You could consider adding the CVS revision numbers as notes (see \"git help \n> notes\" in >= v1.6.6) to the corresponding commits. Then they don't pollute \n> the commit messages, but instead live in a separate, but parallel hierarchy \n> that can be easily pulled in when you need to reference them (e.g. \n> GIT_NOTES_REF=\"refs/\" git log).\n\nThanks, looks better than munging the log. Though with one common\nweakness - should likely omit noting mass commits, since they'd clutter\nwhat 'git log' displays too much. Of course, either could used combined\nwith a mapping table.\n\n-- \nHallvard\n"},{"id":"132840","messageId":"201001272319.30134.johan@herland.net","threadId":"22399","inReplyTo":"hbf.20100127jjbx@bombur.uio.no","subject":"Re: cvs revision number -> git commit name?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-01-27T22:19:30Z","receivedAt":"2010-01-27T22:19:30Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 27 January 2010, Hallvard B Furuseth wrote:\n> Johan Herland writes:\n> > You could consider adding the CVS revision numbers as notes (see \"git\n> > help notes\" in >= v1.6.6) to the corresponding commits. Then they don't\n> > pollute the commit messages, but instead live in a separate, but\n> > parallel hierarchy that can be easily pulled in when you need to\n> > reference them (e.g. GIT_NOTES_REF=\"refs/\" git log).\n> \n> Thanks, looks better than munging the log. Though with one common\n> weakness - should likely omit noting mass commits, since they'd clutter\n> what 'git log' displays too much. Of course, either could used combined\n> with a mapping table.\n\nOf course, you wouldn't put the cvs revision numbers on the default notes \nref (\"refs/notes/commits\"). You would rather put them on a _different_ notes \nrefs (e.g. \"refs/notes/cvs\"), where they would not clutter you \"git log\", \nand then when you _need_ to look at them, you simply run:\n\n GIT_NOTES_REF=refs/notes/cvs git log\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"}]}