{"thread":{"id":"14758","subject":"Feature suggestion: git-hist","startedAt":"2008-07-30T11:38:59Z","lastAt":"2008-07-30T16:34:09Z","messageCount":13,"participants":["H.Merijn Brand","Pieter de Bie","Lars Noschinski","Miklos Vajna","Santi Béjar","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"85599","messageId":"20080730133859.368bbd92@pc09.procura.nl","threadId":"14758","inReplyTo":null,"subject":"Feature suggestion: git-hist","fromName":"H.Merijn Brand","fromEmail":"h.m.brand@xs4all.nl","sentAt":"2008-07-30T11:38:59Z","receivedAt":"2008-07-30T11:38:59Z","isPatch":false,"sender":{"key":"h.m.brand@xs4all.nl","avatar":"https://gravatar.com/avatar/5b8f83ee35c427a646cbea3b104346e00ab3663b99bbf435cddeb75cd4b3857b?d=mp&s=160"},"body":"I've talked about this with Arjen, and he suggested to put it here.\nPlease Cc me too, as I have little time to follow this quite busy list.\n\nSuggestion\n\n\tAdd a new command: 'git-hist' that will show a blame log of a\n\tsingle file with each line `tagged' with the most recent tag\n\tplus the number of changes since that tag.\n\nRelationale.\n\n\tComing from SCCS, each file `keeps' a version in a keyword like\n\t%R%.%L% which is included in the file when a release is made.\n\tThe unix command 'what' will show all SCCS id's when used on a\n\tobject, like\n\n\t% what probev | head -10\n\tprobev:\n\t\t$Revision: 92453-07 linker linker crt0.o B.11.60 070209$\n\t\tprobev.ic 5.27 [07/11/14]\n\t\tMake info: HP-UX B.11.00 9000/800; 14 Jul 2008, 14:52; v04.3.6.04:v82BC anrs.ic 5.5 [07/04/10]\n\t\tarsmon.ic 5.19 [08/07/09]\n\t\tcontrole.ic 5.40 [2008-03-18]\n\t\tgoedmut.ic 5.19 [07/05/16]\n\t\tgvh.ic 5.8 [06/06/13]\n\t\tinw.ic 5.8 [06/06/12]\n\n\tAll software has bugs, so has ours, and we ship updates, just as\n\tgit makes updates available to the world. I just updated to the\n\tmost recent 1.5.6.4.\n\n\tWe make our updates available to our customers, but they\n\tsometimes wait weeks or months to install the updates, but still\n\tcomplain about bugs that already have been fixed and for which\n\tthey already received an update.\n\n\tI can ask them what version they have, and I can then check if\n\tthe complaint was already addressed in an update that was\n\talready released. In SCCS this was easy: they tell me the output\n\tof the what command, I check if the bug was fixed in a newer\n\tversion and the answer is present. No such luck in git, as the\n\tstamps are (non-sequitive) SHA id's. As we moved to git, we now\n\thave to update those id's by hand, as the customers are used to\n\tit. (At least we can now use readable date formats)\n\nImplementation\n\n\tAttached is my perl script git-hist, which is how I currently\n\tuse it, which will show the blame log of a file, with each line\n\tprefixed with the tag plus changes since. So I can tell that if\n\tthe customer runs release version 0.34, the line in question has\n\tbeen added before or after.\n\n\t* Tag all releases with a version number like 5.10.0 or\n5.10.1-RC2\n (give or take the annoying quircks that git refuses some characters\n in tag names, which changed without warning in the 1.5.x track so\n I had to manually rename all my 'v 0.53' tags to loose the space)\n * Count changes since last tag\n\n# git-hist *pm | perl -ne'63..83 and print'\n09d4472 2007-12-06 13:25:58 63: allow_loose_quotes => 0,\n09d4472 2007-12-06 13:25:58 64: allow_loose_escapes => 0,\n09d4472 2007-12-06 13:25:58 65: allow_whitespace => 0,\ncaf4798 2008-02-19 17:56:36 0.34 + 004 66: blank_is_undef => 0,\n09d4472 2007-12-06 13:25:58 67: verbatim => 0,\n09d4472 2007-12-06 13:25:58 68: types => undef,\n09d4472 2007-12-06 13:25:58 69:\n8648db0 2008-03-27 18:37:54 0.37 + 002 70:\n09d4472 2007-12-06 13:25:58 71: _EOF => 0,\n09d4472 2007-12-06 13:25:58 72: _STATUS => undef,\n09d4472 2007-12-06 13:25:58 73: _FIELDS => undef,\n09d4472 2007-12-06 13:25:58 74: _FFLAGS => undef,\n09d4472 2007-12-06 13:25:58 75: _STRING => undef,\n09d4472 2007-12-06 13:25:58 76: _ERROR_INPUT => undef,\n2b95026 2008-04-04 11:10:09 0.37 + 006 77: _COLUMN_NAMES => undef,\nce53d02 2008-04-06 00:40:26 0.37 + 016 78: _BOUND_COLUMNS => undef,\n09d4472 2007-12-06 13:25:58 79: );\ncaf4798 2008-02-19 17:56:36 0.34 + 004 80: my $last_new_err = \"\";\n09d4472 2007-12-06 13:25:58 81:\n09d4472 2007-12-06 13:25:58 82: sub new\n09d4472 2007-12-06 13:25:58 83: {\n\n\tOr for a perl file\n\n# git-hist xsutils.c | perl -ne'30..50 and print'\n02ca0a6 2005-04-21 17:38:30 perl-5.9.2 + 104 30: PERL_XS_EXPORT_C void XS_attributes_bootstrap(pTHX_ CV *cv);\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 31:\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 32:\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 33: /*\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 34: * Note that only ${pkg}::bootstrap definitions should go here.\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 35: * This helps keep down the start-up time, which is especially\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 36: * relevant for users who don't invoke any features which are\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 37: * (partially) implemented here.\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 38: *\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 39: * The various bootstrap definitions can take care of doing\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 40: * package-specific newXS() calls. Since the layout of the\n2136f35 2000-02-04 05:58:57 perl-5.005 + 2832 41: * bundled *.pm files is in a version-specific directory,\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 42: * version checks in these bootstrap calls are optional.\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 43: */\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 44:\n02d011f 2006-05-02 19:46:38 perl-5.9.3 + 950 45: static const char file[] = __FILE__;\n02d011f 2006-05-02 19:46:38 perl-5.9.3 + 950 46:\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 47: void\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 48: Perl_boot_core_xsutils(pTHX)\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 49: {\nd66c5aa 1999-09-07 19:25:07 perl-5.005 + 1988 50: newXS(\"attributes::bootstrap\", XS_attributes_bootstrap, file);\n\n\n-- \nH.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/\nusing & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,\n11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.\nhttp://mirrors.develooper.com/hpux/ http://www.test-smoke.org/\nhttp://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/\n"},{"id":"85601","messageId":"8B01DD07-7A11-4855-94E6-822D901840E3@ai.rug.nl","threadId":"14758","inReplyTo":"20080730133859.368bbd92@pc09.procura.nl","subject":"Re: Feature suggestion: git-hist","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-07-30T12:03:59Z","receivedAt":"2008-07-30T12:03:59Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 30 jul 2008, at 13:38, H.Merijn Brand wrote:\n\n> I've talked about this with Arjen, and he suggested to put it here.\n> Please Cc me too, as I have little time to follow this quite busy \n> list.\n>\n> Suggestion\n>\n> \tAdd a new command: 'git-hist' that will show a blame log of a\n> \tsingle file with each line `tagged' with the most recent tag\n> \tplus the number of changes since that tag.\n\nYou can do something almost similar with a command like:\n\n\tgit blame -l Makefile | git name-rev --stdin --tags\n\n- Pieter\n"},{"id":"85602","messageId":"20080730141449.75cc8e92@pc09.procura.nl","threadId":"14758","inReplyTo":"8B01DD07-7A11-4855-94E6-822D901840E3@ai.rug.nl","subject":"Re: Feature suggestion: git-hist","fromName":"H.Merijn Brand","fromEmail":"h.m.brand@xs4all.nl","sentAt":"2008-07-30T12:14:49Z","receivedAt":"2008-07-30T12:14:49Z","isPatch":false,"sender":{"key":"h.m.brand@xs4all.nl","avatar":"https://gravatar.com/avatar/5b8f83ee35c427a646cbea3b104346e00ab3663b99bbf435cddeb75cd4b3857b?d=mp&s=160"},"body":"On Wed, 30 Jul 2008 14:03:59 +0200, Pieter de Bie \nwrote:\n\n> \n> On 30 jul 2008, at 13:38, H.Merijn Brand wrote:\n> \n> > I've talked about this with Arjen, and he suggested to put it here.\n> > Please Cc me too, as I have little time to follow this quite busy \n> > list.\n> >\n> > Suggestion\n> >\n> > \tAdd a new command: 'git-hist' that will show a blame log of a\n> > \tsingle file with each line `tagged' with the most recent tag\n> > \tplus the number of changes since that tag.\n> \n> You can do something almost similar with a command like:\n> \n> \tgit blame -l Makefile | git name-rev --stdin --tags\n\nVery noisy compared to my script, but it indeed comes close to what I\nneed. This lacks the overview.\n\n-- \nH.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/\nusing & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,\n11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.\nhttp://mirrors.develooper.com/hpux/ http://www.test-smoke.org/\nhttp://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/\n"},{"id":"85617","messageId":"20080730133334.GB31192@lars.home.noschinski.de","threadId":"14758","inReplyTo":"20080730133859.368bbd92@pc09.procura.nl","subject":"Re: Feature suggestion: git-hist","fromName":"Lars Noschinski","fromEmail":"lars-2008-1@usenet.noschinski.de","sentAt":"2008-07-30T13:33:34Z","receivedAt":"2008-07-30T13:33:34Z","isPatch":false,"sender":{"key":"lars-2008-1@usenet.noschinski.de","avatar":null},"body":"* H.Merijn Brand [08-07-30 13:38]:\n\n>\tI can ask them what version they have, and I can then check if\n>\tthe complaint was already addressed in an update that was\n>\talready released. In SCCS this was easy: they tell me the output\n>\tof the what command, I check if the bug was fixed in a newer\n>\tversion and the answer is present. No such luck in git, as the\n>\tstamps are (non-sequitive) SHA id's. As we moved to git, we now\n>\thave to update those id's by hand, as the customers are used to\n>\tit. (At least we can now use readable date formats)\n\nHm, what about \"git-describe --contains $SHA_OF_BUGFIX\"?\n"},{"id":"85622","messageId":"20080730155835.71289eee@pc09.procura.nl","threadId":"14758","inReplyTo":"20080730133334.GB31192@lars.home.noschinski.de","subject":"Re: Feature suggestion: git-hist","fromName":"H.Merijn Brand","fromEmail":"h.m.brand@xs4all.nl","sentAt":"2008-07-30T13:58:35Z","receivedAt":"2008-07-30T13:58:35Z","isPatch":false,"sender":{"key":"h.m.brand@xs4all.nl","avatar":"https://gravatar.com/avatar/5b8f83ee35c427a646cbea3b104346e00ab3663b99bbf435cddeb75cd4b3857b?d=mp&s=160"},"body":"On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski\n wrote:\n\n> * H.Merijn Brand [08-07-30 13:38]:\n> \n> >\tI can ask them what version they have, and I can then check if\n> >\tthe complaint was already addressed in an update that was\n> >\talready released. In SCCS this was easy: they tell me the output\n> >\tof the what command, I check if the bug was fixed in a newer\n> >\tversion and the answer is present. No such luck in git, as the\n> >\tstamps are (non-sequitive) SHA id's. As we moved to git, we now\n> >\thave to update those id's by hand, as the customers are used to\n> >\tit. (At least we can now use readable date formats)\n> \n> Hm, what about \"git-describe --contains $SHA_OF_BUGFIX\"?\n\nIf you come from a SCCS environment, the developers are used to see the\nversion of a single file, not of the id of a fix. One of the reasons we\nmoved from SCCS to git, is that we now can commit a group of files as a\nsingle commit, and later look at the complete picture.\n\nWe are not used to working with $SHA's, and IMHO from the end-user pov,\na $SHA is less user friendly than a release number or a file version. I\ncan remember a version, but I cannot remember a SHA.\n\nThe end user only has the application, which is (or at least should be)\nable to spit out its release version. That is all we can go by when we\ndig back into the history to see where we changed things.\n\nOne (very) big disadvantage of SCCS is that commits are on a per-file\nbasis, and only in a single directory. This drawback still haunts me in\ngit, as my first attempts to convert were successful in a single folder\nand git cannot merge folders into a single project.\n\nSay I now have\n\n/work/src/project/.git\n/work/src/project/module_a/.git\n/work/src/project/module_b/.git\n/work/src/project/module_c/.git\n\nWhich are all converted repos from SCCS, I'd like to merge the three\nmodule_# repos into the top level repo.\n\n-- \nH.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/\nusing & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,\n11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.\nhttp://mirrors.develooper.com/hpux/ http://www.test-smoke.org/\nhttp://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/\n"},{"id":"85630","messageId":"20080730145534.GD32057@genesis.frugalware.org","threadId":"14758","inReplyTo":"20080730155835.71289eee@pc09.procura.nl","subject":"Re: Feature suggestion: git-hist","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-07-30T14:55:34Z","receivedAt":"2008-07-30T14:55:34Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Jul 30, 2008 at 03:58:35PM +0200, \"H.Merijn Brand\" wrote:\n> We are not used to working with $SHA's, and IMHO from the end-user pov,\n> a $SHA is less user friendly than a release number or a file version. I\n> can remember a version, but I cannot remember a SHA.\n\nBut a version is never unique in a distributed environment. So a version\nis useless without at least an abbreviated hash.\n\nIf pure hashes are not friendly enough, you can use something like:\n\ngit describe $(git rev-list -1 HEAD -- )\n\nto get the _hash_ of the _commit_ (ie. not the version of a file) that\ntouched the file last time.\n"},{"id":"85634","messageId":"20080730170326.6f4f1772@pc09.procura.nl","threadId":"14758","inReplyTo":"20080730145534.GD32057@genesis.frugalware.org","subject":"Re: Feature suggestion: git-hist","fromName":"H.Merijn Brand","fromEmail":"h.m.brand@xs4all.nl","sentAt":"2008-07-30T15:03:26Z","receivedAt":"2008-07-30T15:03:26Z","isPatch":false,"sender":{"key":"h.m.brand@xs4all.nl","avatar":"https://gravatar.com/avatar/5b8f83ee35c427a646cbea3b104346e00ab3663b99bbf435cddeb75cd4b3857b?d=mp&s=160"},"body":"On Wed, 30 Jul 2008 16:55:34 +0200, Miklos Vajna\n wrote:\n\n> On Wed, Jul 30, 2008 at 03:58:35PM +0200, \"H.Merijn Brand\" wrote:\n> > We are not used to working with $SHA's, and IMHO from the end-user pov,\n> > a $SHA is less user friendly than a release number or a file version. I\n> > can remember a version, but I cannot remember a SHA.\n> \n> But a version is never unique in a distributed environment. So a version\n> is useless without at least an abbreviated hash.\n\nWhich is exactly what my git-hist does:\n\n# git-hist *pm | perl -ne'63..83 and print'\n09d4472 2007-12-06 13:25:58 63: allow_loose_quotes => 0,\n09d4472 2007-12-06 13:25:58 64: allow_loose_escapes => 0,\n09d4472 2007-12-06 13:25:58 65: allow_whitespace => 0,\ncaf4798 2008-02-19 17:56:36 0.34 + 004 66: blank_is_undef => 0,\n09d4472 2007-12-06 13:25:58 67: verbatim => 0,\n09d4472 2007-12-06 13:25:58 68: types => undef,\n09d4472 2007-12-06 13:25:58 69:\n8648db0 2008-03-27 18:37:54 0.37 + 002 70:\n09d4472 2007-12-06 13:25:58 71: _EOF => 0,\n09d4472 2007-12-06 13:25:58 72: _STATUS => undef,\n09d4472 2007-12-06 13:25:58 73: _FIELDS => undef,\n09d4472 2007-12-06 13:25:58 74: _FFLAGS => undef,\n09d4472 2007-12-06 13:25:58 75: _STRING => undef,\n09d4472 2007-12-06 13:25:58 76: _ERROR_INPUT => undef,\n2b95026 2008-04-04 11:10:09 0.37 + 006 77: _COLUMN_NAMES => undef,\nce53d02 2008-04-06 00:40:26 0.37 + 016 78: _BOUND_COLUMNS => undef,\n09d4472 2007-12-06 13:25:58 79: );\ncaf4798 2008-02-19 17:56:36 0.34 + 004 80: my $last_new_err = \"\";\n09d4472 2007-12-06 13:25:58 81:\n09d4472 2007-12-06 13:25:58 82: sub new\n09d4472 2007-12-06 13:25:58 83: {\n\n> If pure hashes are not friendly enough, you can use something like:\n> \n> git describe $(git rev-list -1 HEAD -- )\n\nWhat do I miss here?\n\n> git describe $(git rev-list -1 HEAD -- *pm)\nfatal: cannot describe 'c2220c8a544af5cd5419e238eb5f43b1f079ad85'\n\n> to get the _hash_ of the _commit_ (ie. not the version of a file) that\n> touched the file last time.\n\nMy git-hist is just a perl script that collects the combined\ninformation of\n\n\tgit-log --pretty=format:'%h %ct %s'\n\tgit-show-ref --tags\nand\tgit-blame file\n\nI could also make it a reformatting wrapper over several calls to\n\n\tgit blame -l file | git name-rev --stdin --tags\n\nWhich is probably faster for a single file, but slower on multiple files\n\n-- \nH.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/\nusing & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,\n11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.\nhttp://mirrors.develooper.com/hpux/ http://www.test-smoke.org/\nhttp://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/\n"},{"id":"85635","messageId":"8aa486160807300818m108920a0pe4a5de47de8d838c@mail.gmail.com","threadId":"14758","inReplyTo":"20080730155835.71289eee@pc09.procura.nl","subject":"Re: Feature suggestion: git-hist","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-07-30T15:18:59Z","receivedAt":"2008-07-30T15:18:59Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand wrote:\n> On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski\n> wrote:\n>\n>> * H.Merijn Brand [08-07-30 13:38]:\n>>\n>> > I can ask them what version they have, and I can then check if\n>> > the complaint was already addressed in an update that was\n>> > already released. In SCCS this was easy: they tell me the output\n>> > of the what command, I check if the bug was fixed in a newer\n>> > version and the answer is present. No such luck in git, as the\n>> > stamps are (non-sequitive) SHA id's. As we moved to git, we now\n>> > have to update those id's by hand, as the customers are used to\n>> > it. (At least we can now use readable date formats)\n>>\n>> Hm, what about \"git-describe --contains $SHA_OF_BUGFIX\"?\n>\n> If you come from a SCCS environment, the developers are used to see the\n> version of a single file, not of the id of a fix. One of the reasons we\n> moved from SCCS to git, is that we now can commit a group of files as a\n> single commit, and later look at the complete picture.\n>\n> We are not used to working with $SHA's, and IMHO from the end-user pov,\n> a $SHA is less user friendly than a release number or a file version. I\n> can remember a version, but I cannot remember a SHA.\n\n>\n> The end user only has the application, which is (or at least should be)\n> able to spit out its release version.\n\nAs git itself does:\n\n$ git version\ngit version 1.6.0.rc1.11.g1ce47\n\nI think it is far better to know the version of the entire project,\nthan the version of a single file.\n\n> That is all we can go by when we\n> dig back into the history to see where we changed things.\n>\n> One (very) big disadvantage of SCCS is that commits are on a per-file\n> basis, and only in a single directory. This drawback still haunts me in\n> git, as my first attempts to convert were successful in a single folder\n> and git cannot merge folders into a single project.\n>\n> Say I now have\n>\n> /work/src/project/.git\n> /work/src/project/module_a/.git\n> /work/src/project/module_b/.git\n> /work/src/project/module_c/.git\n>\n> Which are all converted repos from SCCS, I'd like to merge the three\n> module_# repos into the top level repo.\n\nYou have, basically, two possibilities:\n\n1) Add the module_# as submodules:\n http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html\n http://git.or.cz/gitwiki/GitSubmoduleTutorial\n2) Add the submodules as subtrees (as gitk and git-gui in git.git)\n http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html\n\nSanti\n"},{"id":"85636","messageId":"8aa486160807300823w3dfbdff2m4b9821d71779231d@mail.gmail.com","threadId":"14758","inReplyTo":"20080730170326.6f4f1772@pc09.procura.nl","subject":"Re: Feature suggestion: git-hist","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-07-30T15:23:25Z","receivedAt":"2008-07-30T15:23:25Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Wed, Jul 30, 2008 at 17:03, H.Merijn Brand wrote:\n> On Wed, 30 Jul 2008 16:55:34 +0200, Miklos Vajna\n> wrote:\n>\n>> If pure hashes are not friendly enough, you can use something like:\n>>\n>> git describe $(git rev-list -1 HEAD -- )\n>\n> What do I miss here?\n>\n>> git describe $(git rev-list -1 HEAD -- *pm)\n> fatal: cannot describe 'c2220c8a544af5cd5419e238eb5f43b1f079ad85'\n>\n\nIt cannot be described because there is no annotated tag before this\ncommit. Add --always to show the abbreviated commit as fallback.\n\nSanti\n"},{"id":"85638","messageId":"20080730172928.5b9ed2c8@pc09.procura.nl","threadId":"14758","inReplyTo":"8aa486160807300818m108920a0pe4a5de47de8d838c@mail.gmail.com","subject":"Re: Feature suggestion: git-hist","fromName":"H.Merijn Brand","fromEmail":"h.m.brand@xs4all.nl","sentAt":"2008-07-30T15:29:28Z","receivedAt":"2008-07-30T15:29:28Z","isPatch":false,"sender":{"key":"h.m.brand@xs4all.nl","avatar":"https://gravatar.com/avatar/5b8f83ee35c427a646cbea3b104346e00ab3663b99bbf435cddeb75cd4b3857b?d=mp&s=160"},"body":"On Wed, 30 Jul 2008 17:18:59 +0200, \"Santi Béjar\" \nwrote:\n\n> On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand wrote:\n> > On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski\n> > wrote:\n> >\n> >> * H.Merijn Brand [08-07-30 13:38]:\n> >>\n> >> > I can ask them what version they have, and I can then check if\n> >> > the complaint was already addressed in an update that was\n> >> > already released. In SCCS this was easy: they tell me the output\n> >> > of the what command, I check if the bug was fixed in a newer\n> >> > version and the answer is present. No such luck in git, as the\n> >> > stamps are (non-sequitive) SHA id's. As we moved to git, we now\n> >> > have to update those id's by hand, as the customers are used to\n> >> > it. (At least we can now use readable date formats)\n> >>\n> >> Hm, what about \"git-describe --contains $SHA_OF_BUGFIX\"?\n> >\n> > If you come from a SCCS environment, the developers are used to see the\n> > version of a single file, not of the id of a fix. One of the reasons we\n> > moved from SCCS to git, is that we now can commit a group of files as a\n> > single commit, and later look at the complete picture.\n> >\n> > We are not used to working with $SHA's, and IMHO from the end-user pov,\n> > a $SHA is less user friendly than a release number or a file version. I\n> > can remember a version, but I cannot remember a SHA.\n> \n> >\n> > The end user only has the application, which is (or at least should be)\n> > able to spit out its release version.\n> \n> As git itself does:\n> \n> $ git version\n> git version 1.6.0.rc1.11.g1ce47\n> \n> I think it is far better to know the version of the entire project,\n> than the version of a single file.\n\nYes. I agree.\nWe us tags to `mark' the release, but with the repo's of a project\n(still) scattered around, it is far from ideal.\n\nAnd as to a single file: I mostly know (when I fixed something) in what\nfile I fixed it, so the first thing I do is to check that file against\nthe revision that the customer runs.\n\n> > That is all we can go by when we dig back into the history to see where\n> > we changed things.\n> >\n> > One (very) big disadvantage of SCCS is that commits are on a per-file\n> > basis, and only in a single directory. This drawback still haunts me in\n> > git, as my first attempts to convert were successful in a single folder\n> > and git cannot merge folders into a single project.\n> >\n> > Say I now have\n> >\n> > /work/src/project/.git\n> > /work/src/project/module_a/.git\n> > /work/src/project/module_b/.git\n> > /work/src/project/module_c/.git\n> >\n> > Which are all converted repos from SCCS, I'd like to merge the three\n> > module_# repos into the top level repo.\n> \n> You have, basically, two possibilities:\n> \n> 1) Add the module_# as submodules:\n> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html\n> http://git.or.cz/gitwiki/GitSubmoduleTutorial\n> 2) Add the submodules as subtrees (as gitk and git-gui in git.git)\n> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html\n\nThanks, I'll start reading ...\n\n-- \nH.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/\nusing & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,\n11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.\nhttp://mirrors.develooper.com/hpux/ http://www.test-smoke.org/\nhttp://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/\n"},{"id":"85644","messageId":"32541b130807300858r152d7428j404eaefc04f606@mail.gmail.com","threadId":"14758","inReplyTo":"8aa486160807300823w3dfbdff2m4b9821d71779231d@mail.gmail.com","subject":"Re: Feature suggestion: git-hist","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-30T15:58:57Z","receivedAt":"2008-07-30T15:58:57Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar wrote:\n> It cannot be described because there is no annotated tag before this\n> commit. Add --always to show the abbreviated commit as fallback.\n\nOr --tags to include non-annotated tags.\n\nAvery\n"},{"id":"85649","messageId":"20080730182648.393cfccc@pc09.procura.nl","threadId":"14758","inReplyTo":"FA2D570A-B2B1-4994-AA6A-9C0C55E69900@silverinsanity.com","subject":"Re: Merging submodules (was Re: Feature suggestion: git-hist)","fromName":"H.Merijn Brand","fromEmail":"h.m.brand@xs4all.nl","sentAt":"2008-07-30T16:26:48Z","receivedAt":"2008-07-30T16:26:48Z","isPatch":false,"sender":{"key":"h.m.brand@xs4all.nl","avatar":"https://gravatar.com/avatar/5b8f83ee35c427a646cbea3b104346e00ab3663b99bbf435cddeb75cd4b3857b?d=mp&s=160"},"body":"On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt\n wrote:\n\n> \n> On Jul 30, 2008, at 9:58 AM, H.Merijn Brand wrote:\n> \n> > One (very) big disadvantage of SCCS is that commits are on a per- \n> > file\n> > basis, and only in a single directory. This drawback still haunts me \n> > in\n> > git, as my first attempts to convert were successful in a single \n> > folder\n> > and git cannot merge folders into a single project.\n> >\n> > Say I now have\n> >\n> > /work/src/project/.git\n> > /work/src/project/module_a/.git\n> > /work/src/project/module_b/.git\n> > /work/src/project/module_c/.git\n> >\n> > Which are all converted repos from SCCS, I'd like to merge the three\n> > module_# repos into the top level repo.\n> \n> Following the example of Linus, the following is completely untested.\n> \n> First you fetch all of the heads/tags/etc into the superproject with \n> commands like\n> \n> git fetch module_a refs/heads/*:refs/remotes/module_a/*\n> git fetch module_b refs/heads/*:refs/remotes/module_b/*\n> git fetch module_c refs/heads/*:refs/remotes/module_c/*\n\nAll went well\n \n> Then you do something like:\n> \n> rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...\n> git add module_a module_b module_c\n> git commit # Needed because '-s ours' uses current HEAD, not index\n\nSo far so good.\n\n> git merge --no-commit -s ours module_a/master module_b/master module_c/master\n\n$ git merge --no-commit -s ours fnc/master i00f000/master\ni99f000/master include/master l00m000/master l01f000/master l02f000/master l03f000/master l06f000/master l90z000/master leerpl/master mutbev/master prtabel/master rpt/master tabellen/master zoomen/master Automatic merge went well; stopped before committing as requested\n\n> git commit --amend\n\n$ git commit --amend\nfatal: You are in the middle of a merge -- cannot amend.\n$ git status\n# On branch master\nnothing to commit (working directory clean)\n\nWhen I start git-gui, it still shows a long commit message:\nMerge commit 'fnc/master'; commit 'i00f000/master'; commit 'i99f000/master'; commit 'include/master'; commit 'l00m000/master'; commit 'l01f000/master'; commit 'l02f000/master'; commit 'l03f000/master'; commit 'l06f000/master'; commit 'l90z000/master'; commit 'leerpl/master'; commit 'mutbev/master'; commit 'prtabel/master'; commit 'rpt/master'; commit 'tabellen/master'; commit 'zoomen/master'\n\nAll other areas are clear\n\n> From this point on, the project repository has a merged history of \n> the sub-projects, and if anyone doesn't catch up and still makes a \n> commit on a subproject you can use \"git merge -s subtree\" to merge it \n> in anyway.\n> \n> You may need to \"git rm --cached\" some files after the \"git add\" step \n> if your .gitignore files aren't perfect.\n\n-- \nH.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/\nusing & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,\n11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.\nhttp://mirrors.develooper.com/hpux/ http://www.test-smoke.org/\nhttp://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/\n"},{"id":"85650","messageId":"20080730163408.GA1859@lars.home.noschinski.de","threadId":"14758","inReplyTo":"32541b130807300858r152d7428j404eaefc04f606@mail.gmail.com","subject":"Re: Feature suggestion: git-hist","fromName":"Lars Noschinski","fromEmail":"lars@public.noschinski.de","sentAt":"2008-07-30T16:34:09Z","receivedAt":"2008-07-30T16:34:09Z","isPatch":false,"sender":{"key":"lars@public.noschinski.de","avatar":"https://gravatar.com/avatar/ca62bd8b265f2e26c89d39a4bfe7e390bfa6b16d6400e186e222d1c2382c66f2?d=mp&s=160"},"body":"* Avery Pennarun [08-07-30 18:26]:\n>On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar wrote:\n>> It cannot be described because there is no annotated tag before this\n>> commit. Add --always to show the abbreviated commit as fallback.\n>\n>Or --tags to include non-annotated tags.\n\nFor the intended use case, --contains; as the OP wants to know the\noldest version, which contains this commit.\n"}]}