{"thread":{"id":"95","subject":"[PATCH] Add help details to git help command.","startedAt":"2005-04-18T04:42:26Z","lastAt":"2005-04-23T23:41:01Z","messageCount":16,"participants":["Steven Cole","Petr Baudis","David Greaves"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"625","messageId":"200504172242.26326.elenstev@mesatop.com","threadId":"95","inReplyTo":null,"subject":"[PATCH] Add help details to git help command.","fromName":"Steven Cole","fromEmail":"elenstev@mesatop.com","sentAt":"2005-04-18T04:42:26Z","receivedAt":"2005-04-18T04:42:26Z","isPatch":true,"sender":{"key":"elenstev@mesatop.com","avatar":null},"body":"There's a patch at the bottom of this, so please look at that first before\nmy reading my whining immediately below.\n\nI'm having some troubles with git pull, so this is just an ordinary diff.\nOtherwise, I would have used the in-house diff command.\n\n<troubles>\npatch: **** Only garbage was found in the patch input.\n</troubles>\n<more troubles>\nTracked branch, applying changes...\nerror: bad signature\nerror: verify header failed\nread_cache: Invalid argument\nerror: bad signature\nerror: verify header failed\nerror: bad signature\nerror: verify header failed\n</more troubles>\n\nAnyway, it's late, and I'm sure there is an easy fix to the above.\n\nHere is a patch which provides the comment lines in the associated\nscript files when the git help command is invoked with an argument\nthusly:\n\n[steven@spc git-pasky-new]$ ./git help merge\n\n Merge a branch to the current tree.\n Copyright (c) Petr Baudis, 2005\n\n Takes a parameter identifying the branch to be merged.\n Optional \"-b base_commit\" parameter specifies the base for the\n merge. \"-a\" parameter may come first to tell git merge\n to check out the full tree to the merge tree.\n\n It creates a new ,,merge/ directory, which is git-controlled\n but has only the changed files checked out. You then have to\n examine it and then do git commit, which will also automatically\n bring your working tree up-to-date.\n\n---------\nThis patch will provide the comment lines in the shell script associated\nwith the command, cleaned up a bit for presentation.\n\nBUGS: This will also print any comments in the entire file, which may\nnot be desired.  If a command name and shell script filename\ndo not follow the usual convention, this won't work, e.g. ci for commit.\n\nSigned-off-by: Steven Cole <elenstev@mesatop.com>\n\n--- gp-newest-orig/git\t2005-04-17 22:16:55.000000000 -0600\n+++ gp-newest/git\t2005-04-17 22:19:49.000000000 -0600\n@@ -19,6 +19,11 @@\n \n \n help () {\n+\n+command=$1\n+scriptfile=git$command.sh\n+\n+if [ ! $command ]; then\n \tcat <<__END__\n The GIT scripted toolkit  $(gitversion.sh)\n \n@@ -48,7 +53,10 @@\n \tupdate\t\tCOMMIT_ID\n \tversion\n \n+Additional help is available with: git help COMMAND\n+\n Note that these expressions can be used interchangably as \"ID\"s:\n+\n \tempty string (current HEAD)\n \tlocal (the local branch if tracking a remote one)\n \tremote name (as registered with git addremote)\n@@ -57,6 +65,10 @@\n \tcommit object hash (as returned by commit-id)\n \ttree object hash (accepted only by some commands)\n __END__\n+fi\n+if [ ! $scriptfile = \"git.sh\" ]; then\n+grep ^# $scriptfile | grep -v \"!/bin\" | cut -c 2-\n+fi\n }\n \n \n"},{"id":"639","messageId":"20050418102412.GJ1461@pasky.ji.cz","threadId":"95","inReplyTo":"200504172242.26326.elenstev@mesatop.com","subject":"Re: [PATCH] Add help details to git help command.","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-18T10:24:12Z","receivedAt":"2005-04-18T10:24:12Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter\nwhere Steven Cole <elenstev@mesatop.com> told me that...\n> There's a patch at the bottom of this, so please look at that first before\n> my reading my whining immediately below.\n> \n> I'm having some troubles with git pull, so this is just an ordinary diff.\n> Otherwise, I would have used the in-house diff command.\n> \n> <troubles>\n> patch: **** Only garbage was found in the patch input.\n> </troubles>\n> <more troubles>\n> Tracked branch, applying changes...\n> error: bad signature\n> error: verify header failed\n> read_cache: Invalid argument\n> error: bad signature\n> error: verify header failed\n> error: bad signature\n> error: verify header failed\n> </more troubles>\n\nread-tree $(tree-id) && update-cache --refresh\n\nThe directory cache format changed, so it causes this. I'm hoping to\nrelease 0.5 with good cache prepackaged Real Soon Now (tm). :-)\n\nNote that then you will have to recover from the failed apply. If you\nhad no local commits, it is easy - put that two IDs git pull told\nyou to git diff and pipe it to git apply. If you had local commits, and\nhave already GIT version with merge-base, do just git merge pasky and\nproceed with the merge. If you don't have merge-base, pass the first\nID from git track to git merge with the -b argument.\n\n> This patch will provide the comment lines in the shell script associated\n> with the command, cleaned up a bit for presentation.\n> \n> BUGS: This will also print any comments in the entire file, which may\n> not be desired.  If a command name and shell script filename\n> do not follow the usual convention, this won't work, e.g. ci for commit.\n\nHey, those BUGS are the only slightly non-trivial thing on the whole\nthing! I could do this patch myself... ;-) Also, you don't want to print\nthe first newline and the Copyright notices.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"670","messageId":"4263E782.6040608@mesatop.com","threadId":"95","inReplyTo":"20050418102412.GJ1461@pasky.ji.cz","subject":"Re: [PATCH] Add help details to git help command.","fromName":"Steven Cole","fromEmail":"elenstev@mesatop.com","sentAt":"2005-04-18T16:59:46Z","receivedAt":"2005-04-18T16:59:46Z","isPatch":true,"sender":{"key":"elenstev@mesatop.com","avatar":null},"body":"Petr Baudis wrote:\n> Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter\n> where Steven Cole <elenstev@mesatop.com> told me that...\n[snippage]\n> \n>>This patch will provide the comment lines in the shell script associated\n>>with the command, cleaned up a bit for presentation.\n>>\n>>BUGS: This will also print any comments in the entire file, which may\n>>not be desired.  If a command name and shell script filename\n>>do not follow the usual convention, this won't work, e.g. ci for commit.\n> \n> \n> Hey, those BUGS are the only slightly non-trivial thing on the whole\n> thing! I could do this patch myself... ;-) Also, you don't want to print\n> the first newline and the Copyright notices.\n> \n\nFixed extra vertical whitespace, Copyright notice problems, and issue\nwith git help ci.\n\nHere's a better version.  Didn't fix the more interesting bugs, as I'm\npressed for time (aren't we all).  Perhaps someone can polish this up.\n\nAnyway, I think it's pretty useful in its present form.\n\nThanks,\nSteven\n\n---------\n\nThis patch will provide the comment lines in the shell script associated\nwith the command, cleaned up a bit for presentation.\n\nBUGS: This will also print any comments in the entire file, which may\nnot be desired.  If a command name and shell script filename\ndo not follow the usual convention, this won't work.\n\ngit: b648169640025bd68d1b27a0fcc85b65d85e4440\n--- git\n+++ git\t2005-04-18 10:34:17.000000000 -0600\n@@ -19,6 +19,11 @@\n\n\n  help () {\n+\n+command=$1\n+scriptfile=git$command.sh\n+\n+if [ ! $command ]; then\n  \tcat <<__END__\n  The GIT scripted toolkit  $(gitversion.sh)\n\n@@ -48,7 +53,10 @@\n  \ttrack\t\t[RNAME]\n  \tversion\n\n+Additional help is available with: git help COMMAND\n+\n  Note that these expressions can be used interchangably as \"ID\"s:\n+\n  \tempty string (current HEAD)\n  \tlocal (the local branch if tracking a remote one)\n  \tremote name (as registered with git addremote)\n@@ -57,6 +65,14 @@\n  \tcommit object hash (as returned by commit-id)\n  \ttree object hash (accepted only by some commands)\n  __END__\n+fi\n+if [ $scriptfile = \"gitci.sh\" ]; then\n+\tscriptfile=\"gitcommit.sh\"\n+fi\n+if [ ! $scriptfile = \"git.sh\" ]; then\n+\tgrep ^# $scriptfile | grep -v \"!/bin\" | grep -v \"(c)\" \\\n+\t| cut -c 2- | grep ^.\n+fi\n  }\n\n\n\n"},{"id":"758","messageId":"200504181940.54453.elenstev@mesatop.com","threadId":"95","inReplyTo":"4263E782.6040608@mesatop.com","subject":"[RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)","fromName":"Steven Cole","fromEmail":"elenstev@mesatop.com","sentAt":"2005-04-19T01:40:54Z","receivedAt":"2005-04-19T01:40:54Z","isPatch":true,"sender":{"key":"elenstev@mesatop.com","avatar":null},"body":"On Monday 18 April 2005 10:59 am, Steven Cole wrote:\n> Petr Baudis wrote:\n> > Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter\n> > where Steven Cole <elenstev@mesatop.com> told me that...\n> [snippage]\n> > \n> >>This patch will provide the comment lines in the shell script associated\n> >>with the command, cleaned up a bit for presentation.\n> >>\n> >>BUGS: This will also print any comments in the entire file, which may\n> >>not be desired.  If a command name and shell script filename\n> >>do not follow the usual convention, this won't work, e.g. ci for commit.\n> > \n> > \n> > Hey, those BUGS are the only slightly non-trivial thing on the whole\n> > thing! I could do this patch myself... ;-) Also, you don't want to print\n> > the first newline and the Copyright notices.\n\nHere is perhaps a better way to provide detailed help for each\ngit command.  A command.help file for each command can be\nwritten in the style of a man page.\n\nThe modfication to the main git script will be trivial. \nHere are the two commands I've done so far.\n\nWhat do folks think about this approach?\n\nSteven\n\n[steven@spc git-pasky]$ ./git help add\nNAME\n        add - Add new file or files to a GIT repository.\n\nSYNOPSIS\n        add FILE...\n\nDESCRIPTION\n        Takes a list of file names at the command line, and schedules them\n        for addition to the GIT repository at the next commit.\n\nAUTHOR\n        Written by Petr Baudis.\n\nREPORTING BUGS\n        Report bugs to <git@vger.kernel.org>\n\nCOPYRIGHT\n        Copyright (c) Petr Baudis, 2005\n\nBUGS\n        Those files are omitted from show-diff output!\n\nSEE ALSO\n        The source code for this command is gitadd.sh.\n\n[steven@spc git-pasky]$ ./git help addremote\nNAME\n        addremote -  Add new \"remote\" to the GIT repository.\n\nSYNOPSIS\n        addremote RNAME RSYNC_URL\n\nDESCRIPTION\n        Takes the remote's name and rsync URL.\n\n        After you add a remote, you can \"git pull\" it whenever you want\n        and it will keep your dircache in sync with it. Its latest commit\n        is accessible as .git/heads/remotename (or - more conveniently -\n        as $(commit-id remotename)). For example, to make a diff between\n        Linus (after you added him) and your current tree, do\n\n        git pull linus\n        git diff $(commit-id linus)\n\nAUTHOR\n        Written by Petr Baudis.\n\nREPORTING BUGS\n        Report bugs to <git@vger.kernel.org>\n\nCOPYRIGHT\n        Copyright (c) Petr Baudis, 2005\n\nTODO\n        gitdiff.sh et al should accept remote names as ids.\n\nSEE ALSO\n        The source code for this command is gitaddremote.sh.\n"},{"id":"761","messageId":"20050419015124.GW5554@pasky.ji.cz","threadId":"95","inReplyTo":"200504181940.54453.elenstev@mesatop.com","subject":"Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-19T01:51:24Z","receivedAt":"2005-04-19T01:51:24Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter\nwhere Steven Cole <elenstev@mesatop.com> told me that...\n> Here is perhaps a better way to provide detailed help for each\n> git command.  A command.help file for each command can be\n> written in the style of a man page.\n\nI don't like it. I think the 'help' command should serve primarily as a\nquick reference, which does not blend so well with a manual page - it's\ntoo long and too convoluted by repeated output.\n\nI'd just print the top comment from each file. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"827","messageId":"4265189E.6090801@dgreaves.com","threadId":"95","inReplyTo":"20050419015124.GW5554@pasky.ji.cz","subject":"Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-04-19T14:41:34Z","receivedAt":"2005-04-19T14:41:34Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Petr Baudis wrote:\n> Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter\n> where Steven Cole <elenstev@mesatop.com> told me that...\n> \n>>Here is perhaps a better way to provide detailed help for each\n>>git command.  A command.help file for each command can be\n>>written in the style of a man page.\n> \n> \n> I don't like it. I think the 'help' command should serve primarily as a\n> quick reference, which does not blend so well with a manual page - it's\n> too long and too convoluted by repeated output.\n> \n> I'd just print the top comment from each file. :-)\n> \n\nOn the other hand, having more complete docs seems like an excellent \nidea (and other threads support that)\nI'd certainly like to see more specification oriented documentation...\n(even if it turns out to be disposable)\n\nSteven, if you carry on sending more verbose docs I'll certainly read \nand work with you on editing them...\n\nNb kernel-doc doesn't seem appropriate for user level docs.\nmaybe, whilst there's so much flux, have:\n   git man command\nthat just outputs text\n\nIf Petr wants the top comment to be extracted by help then maybe a \nbottom comment block could contain the more complete text?\nI *really* think that the user docs should live in the source for now \n(hence I think that git man is better than going straight to man/docbook).\n\nI wasn't sure whether to perlise the code or do a shell-lib - but \nlooking at the algorithms needed in things like git status I reckon the \nshell will end up becoming a hackish mess of awk/sed/tr/sort/uniq/pipe \n(ie perl) anyway.\n\nSo I'm going to have a go at that - Petr, if you have a minute could you \nsend me, off list, a bit of perl code that epitomises the style you like?\n\nDavid\n\n"},{"id":"830","messageId":"42652BDD.5000604@mesatop.com","threadId":"95","inReplyTo":"4265189E.6090801@dgreaves.com","subject":"Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)","fromName":"Steven Cole","fromEmail":"elenstev@mesatop.com","sentAt":"2005-04-19T16:03:41Z","receivedAt":"2005-04-19T16:03:41Z","isPatch":true,"sender":{"key":"elenstev@mesatop.com","avatar":null},"body":"David Greaves wrote:\n> Petr Baudis wrote:\n> \n>> Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter\n>> where Steven Cole <elenstev@mesatop.com> told me that...\n>>\n>>> Here is perhaps a better way to provide detailed help for each\n>>> git command.  A command.help file for each command can be\n>>> written in the style of a man page.\n>>\n>>\n>>\n>> I don't like it. I think the 'help' command should serve primarily as a\n>> quick reference, which does not blend so well with a manual page - it's\n>> too long and too convoluted by repeated output.\n>>\n>> I'd just print the top comment from each file. :-)\n>>\n> \n> On the other hand, having more complete docs seems like an excellent \n> idea (and other threads support that)\n> I'd certainly like to see more specification oriented documentation...\n> (even if it turns out to be disposable)\n> \n> Steven, if you carry on sending more verbose docs I'll certainly read \n> and work with you on editing them...\n\nI only did those first two as a straw man.  Doing the others is a couple\nhours (or less) work, but I don't want to do it if folks don't want it.\n\nHaving the help files separate has advantages/disadvantages.\n\n> \n> Nb kernel-doc doesn't seem appropriate for user level docs.\n> maybe, whilst there's so much flux, have:\n>   git man command\n> that just outputs text\n> \n> If Petr wants the top comment to be extracted by help then maybe a \n> bottom comment block could contain the more complete text?\n> I *really* think that the user docs should live in the source for now \n> (hence I think that git man is better than going straight to man/docbook).\n> \n> I wasn't sure whether to perlise the code or do a shell-lib - but \n> looking at the algorithms needed in things like git status I reckon the \n> shell will end up becoming a hackish mess of awk/sed/tr/sort/uniq/pipe \n> (ie perl) anyway.\n> \n> So I'm going to have a go at that - Petr, if you have a minute could you \n> send me, off list, a bit of perl code that epitomises the style you like?\n> \n> David\n> \n\nFunny you should mention Perl.  Here is small bit of code:\n\n[steven@spc0 git-pasky-testing]$ cat print_help_header.pl\n#!/usr/bin/perl\n# reads from stdin   writes to stdout  no error checking\n<STDIN>;<STDIN>;\nwhile (substr( $line=<STDIN>, 0, 1) eq \"#\") {\n                  print $line;\n}\n\n[steven@spc0 git-pasky-testing]$ ./print_help_header.pl <gitdiff.sh | grep ^# | grep -v \"(c)\" | cut -c 3-\nMake a diff between two GIT trees.\n\nBy default compares the current working tree to the state at the\nlast commit. You can specify -r rev1:rev2 or -r rev1 -r rev2 to\ntell it to make a diff between the specified revisions. If you\ndo not specify a revision, the current working tree is implied\n(note that no revision is different from empty revision - -r rev:\ncompares between rev and HEAD, while -r rev compares between rev\nand working tree).\n\n-p instead of one ID denotes a parent commit to the specified ID\n(which must not be a tree, obviously).\n\nOutputs a diff converting the first tree to the second one.\n-------end of output from perl plus grep and cut.\n\nWithout the perl, extra comments came out (plus the dreaded first blank line).\n\n\n[steven@spc0 git-pasky-testing]$ cat gitdiff.sh | grep -v \"/bin\" | grep ^# | grep -v \"(c)\" | cut -c 3-\n\nMake a diff between two GIT trees.\n\nBy default compares the current working tree to the state at the\nlast commit. You can specify -r rev1:rev2 or -r rev1 -r rev2 to\ntell it to make a diff between the specified revisions. If you\ndo not specify a revision, the current working tree is implied\n(note that no revision is different from empty revision - -r rev:\ncompares between rev and HEAD, while -r rev compares between rev\nand working tree).\n\n-p instead of one ID denotes a parent commit to the specified ID\n(which must not be a tree, obviously).\n\nOutputs a diff converting the first tree to the second one.\nFIXME: The commandline parsing is awful.\n-------end of output from grep and cut.\n\nDavid,\n\nI'm a bit pressed for time, so if you or anyone else would like to\nuse this code to fix up my earlier patch, you're welcome to it.\nOtherwise, it will be later this evening or tomorrow before I can\ndo any more with this.\n\nSteven\n\n"},{"id":"839","messageId":"20050419173238.GJ12757@pasky.ji.cz","threadId":"95","inReplyTo":"4265189E.6090801@dgreaves.com","subject":"Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-19T17:32:38Z","receivedAt":"2005-04-19T17:32:38Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 19, 2005 at 04:41:34PM CEST, I got a letter\nwhere David Greaves <david@dgreaves.com> told me that...\n> If Petr wants the top comment to be extracted by help then maybe a \n> bottom comment block could contain the more complete text?\n> I *really* think that the user docs should live in the source for now \n> (hence I think that git man is better than going straight to man/docbook).\n\nI'd stay with the top comment for now, and go for perldoc in the Perl\nscripts. It's cool, nice, and you can export it to anything and it still\nlooks mostly cute.\n\n> I wasn't sure whether to perlise the code or do a shell-lib - but \n> looking at the algorithms needed in things like git status I reckon the \n> shell will end up becoming a hackish mess of awk/sed/tr/sort/uniq/pipe \n> (ie perl) anyway.\n\nI'm all for slow migration from sh to Perl so that we can add more cream\non the stuff. Shell was great for the first phase of rapid development\n(where basically the most important thing was to be able to call the\ncore git easily, and just wrap it around) but now if you want to do the\nfancier stuff (like git status, or even git log), it's getting more of a\nnuisance.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"842","messageId":"42654153.8080307@mesatop.com","threadId":"95","inReplyTo":"20050418102412.GJ1461@pasky.ji.cz","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"Steven Cole","fromEmail":"elenstev@mesatop.com","sentAt":"2005-04-19T17:35:15Z","receivedAt":"2005-04-19T17:35:15Z","isPatch":true,"sender":{"key":"elenstev@mesatop.com","avatar":null},"body":"Petr Baudis wrote:\n> Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter\n> where Steven Cole <elenstev@mesatop.com> told me that...\n\n[snippage]\n\n> \n>>This patch will provide the comment lines in the shell script associated\n>>with the command, cleaned up a bit for presentation.\n>>\n>>BUGS: This will also print any comments in the entire file, which may\n>>not be desired.  If a command name and shell script filename\n>>do not follow the usual convention, this won't work, e.g. ci for commit.\n> \n> \n> Hey, those BUGS are the only slightly non-trivial thing on the whole\n> thing! I could do this patch myself... ;-) Also, you don't want to print\n> the first newline and the Copyright notices.\n> \n\nOK, here is a patch which _may_ do what you want.\n\nThis one no longer prints comments embedded later in the file,\nand doesn't print the first newline and disposes of the (c) notices\nas requested.  And does the right thing for git help ci.\n\nExample:\n\n[steven@spc0 git-pasky-testing]$ ./git help diff\nMake a diff between two GIT trees.\n\nBy default compares the current working tree to the state at the\nlast commit. You can specify -r rev1:rev2 or -r rev1 -r rev2 to\ntell it to make a diff between the specified revisions. If you\ndo not specify a revision, the current working tree is implied\n(note that no revision is different from empty revision - -r rev:\ncompares between rev and HEAD, while -r rev compares between rev\nand working tree).\n\n-p instead of one ID denotes a parent commit to the specified ID\n(which must not be a tree, obviously).\n\nOutputs a diff converting the first tree to the second one.\n\n---------\nSpeaking of 'git diff', I ran that before applying the following patch,\nand got a diff starting thusly:\n\n  --- /dev/null\n  +++ b/gitmerge-file.sh\n\nI had earlier done a 'git pull pasky', which was 'Up to date'.\n\nSo, the following patch is a conventional diff.\n\nIf the Perl filename or code  is too hideous, you're more than\nwelcome to change it.\n\nSteven\n---------\nThis patch will provide the comment lines in the shell script associated\nwith the command, cleaned up a bit for presentation.\n\nThanks to Bob Newell for some Perl help.\n\nSigned-off-by: Steven Cole <elenstev@mesatop.com>\n\ndiff -urN git-pasky-orig/git git-pasky-testing/git\n--- git-pasky-orig/git\t2005-04-19 10:27:54.000000000 -0600\n+++ git-pasky-testing/git\t2005-04-19 10:19:08.000000000 -0600\n@@ -19,6 +19,11 @@\n\n\n  help () {\n+\n+command=$1\n+scriptfile=git$command.sh\n+\n+if [ ! $command ]; then\n  \tcat <<__END__\n  The GIT scripted toolkit  $(gitversion.sh)\n\n@@ -48,6 +53,8 @@\n  \ttrack\t\t[RNAME]\n  \tversion\n\n+Additional help is available with: git help COMMAND\n+\n  Note that these expressions can be used interchangably as \"ID\"s:\n  \tempty string (current HEAD)\n  \tremote name (as registered with git addremote)\n@@ -56,6 +63,13 @@\n  \tcommit object hash (as returned by commit-id)\n  \ttree object hash (accepted only by some commands)\n  __END__\n+fi\n+if [ $scriptfile = \"gitci.sh\" ]; then\n+\tscriptfile=\"gitcommit.sh\"\n+fi\n+if [ ! $scriptfile = \"git.sh\" ]; then\n+\tprint_help_header.pl <$scriptfile  | grep -v \"(c)\" | cut -c 3-\n+fi\n  }\n\n\ndiff -urN git-pasky-orig/Makefile git-pasky-testing/Makefile\n--- git-pasky-orig/Makefile\t2005-04-19 10:27:54.000000000 -0600\n+++ git-pasky-testing/Makefile\t2005-04-19 10:32:50.000000000 -0600\n@@ -21,7 +21,7 @@\n  \tgitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \\\n  \tgitmerge.sh gitpull.sh gitrm.sh gittag.sh gittrack.sh gitexport.sh \\\n  \tgitapply.sh gitcancel.sh gitXlntree.sh commit-id gitlsremote.sh \\\n-\tgitfork.sh gitinit.sh gitseek.sh gitstatus.sh\n+\tgitfork.sh gitinit.sh gitseek.sh gitstatus.sh print_help_header.pl\n\n  COMMON=\tread-cache.o\n\ndiff -urN git-pasky-orig/print_help_header.pl git-pasky-testing/print_help_header.pl\n--- git-pasky-orig/print_help_header.pl\t1969-12-31 17:00:00.000000000 -0700\n+++ git-pasky-testing/print_help_header.pl\t2005-04-19 10:24:34.000000000 -0600\n@@ -0,0 +1,10 @@\n+#!/usr/bin/perl\n+#\n+# Prints the block of text preceded by #\n+# Copyright (c) Steven Cole, 2005\n+#\n+# reads from stdin   writes to stdout  no error checking\n+<STDIN>;<STDIN>;\n+while (substr( $line=<STDIN>, 0, 1) eq \"#\") {\n+                 print $line;\n+}\n"},{"id":"847","messageId":"20050419175051.GK12757@pasky.ji.cz","threadId":"95","inReplyTo":"42654153.8080307@mesatop.com","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-19T17:50:51Z","receivedAt":"2005-04-19T17:50:51Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter\nwhere Steven Cole <elenstev@mesatop.com> told me that...\n> Example:\n..snip a perfect-looking example..\n> ---------\n> Speaking of 'git diff', I ran that before applying the following patch,\n> and got a diff starting thusly:\n> \n>  --- /dev/null\n>  +++ b/gitmerge-file.sh\n> \n> I had earlier done a 'git pull pasky', which was 'Up to date'.\n\nCheck/prune your add/rm-queue.\n\n> So, the following patch is a conventional diff.\n> \n> If the Perl filename or code  is too hideous, you're more than\n> welcome to change it.\n\nI'd actually prefer to just throw the whole help command handling\nto githelp.pl. I dislike helper scripts if I can avoid them. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"855","messageId":"42655630.80207@dgreaves.com","threadId":"95","inReplyTo":"20050419175051.GK12757@pasky.ji.cz","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-04-19T19:04:16Z","receivedAt":"2005-04-19T19:04:16Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Petr Baudis wrote:\n> Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter\n> where Steven Cole <elenstev@mesatop.com> told me that...\n> \n\nI've been working on git.pl and getting help working nicely\n\nthings to try:\ngit.pl help\ngit.pl add\ngit.pl add --help\ngit.pl add --man\ngit.pl help add\n\nThe main objectives:\n* get a reasonable perl code base in git.pl\n* provide some way to document WTF is going on :)\n* keep the docs near the developer\n* allow variations in verbosity\n* modularise\n* don't use modules outside the base perl set\n* allow a gentle migration (so start by calling the .sh's)\n\nI don't like the pod2usage calling convention but I use them for now.\n\nI don't love the 'require gitadd.pl' but it's a gradual start...\n\nCogito.pm seems to be a good place for the library stuff.\n\ngit.pl\npasses everything to scripts except gitadd.pl\nworks when called from somewhere other than the git dir\nI don't feel 100% about the fixup ports\n\ngitadd.pl\n\n\nI thought I'd ask for comments before I spent too much time on this...\n\nDavid\n\n-- \n"},{"id":"864","messageId":"42656B6B.3080209@mesatop.com","threadId":"95","inReplyTo":"42655630.80207@dgreaves.com","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"Steven Cole","fromEmail":"elenstev@mesatop.com","sentAt":"2005-04-19T20:34:51Z","receivedAt":"2005-04-19T20:34:51Z","isPatch":true,"sender":{"key":"elenstev@mesatop.com","avatar":null},"body":"David Greaves wrote:\n> Petr Baudis wrote:\n> \n>> Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter\n>> where Steven Cole <elenstev@mesatop.com> told me that...\n>>\n> \n> I've been working on git.pl and getting help working nicely\n> \n> things to try:\n> git.pl help\n> git.pl add\n> git.pl add --help\n> git.pl add --man\n> git.pl help add\n> \n> The main objectives:\n> * get a reasonable perl code base in git.pl\n> * provide some way to document WTF is going on :)\n> * keep the docs near the developer\n> * allow variations in verbosity\n> * modularise\n> * don't use modules outside the base perl set\n> * allow a gentle migration (so start by calling the .sh's)\n> \n> I don't like the pod2usage calling convention but I use them for now.\n> \n> I don't love the 'require gitadd.pl' but it's a gradual start...\n> \n> Cogito.pm seems to be a good place for the library stuff.\n> \n> git.pl\n> passes everything to scripts except gitadd.pl\n> works when called from somewhere other than the git dir\n> I don't feel 100% about the fixup ports\n> \n> gitadd.pl\n> \n> \n> I thought I'd ask for comments before I spent too much time on this...\n> \n> David\n> \n\nI only did my version which spits out the comments at the top of the\nshell script as a quick hack.\n\nThis looks good to me. Keeping the docs near the developer is essential,\nI think.  Speaking of \"I think\", the name \"cogito\" was suggested for the\nSCM layer, but IIRC Linus suggested staying with just plain git. Petr\nsuggested tig, perhaps because it looks at git from another point of view.\n\nIf we ever do decide to name the SCM layer (the git-pasky stuff) something\nwith \"git inside\", other choices are:\n\nagitato\t\tBeethoven's \"Moonlight Sonata\" 3rd movment is \"Presto agitato\"\nlegit\t\tSince git is GPLv2, but perhaps a little too French.\nregurgitate\tNo comment neccessary.\n\nSteven\n"},{"id":"865","messageId":"42656DDD.2090907@dgreaves.com","threadId":"95","inReplyTo":"42656B6B.3080209@mesatop.com","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-04-19T20:45:17Z","receivedAt":"2005-04-19T20:45:17Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Steven Cole wrote:\n> Speaking of \"I think\", the name \"cogito\" was suggested for the\n> SCM layer, but IIRC Linus suggested staying with just plain git. Petr\n> suggested tig, perhaps because it looks at git from another point of view.\nI haven't read _all_ the mails - I thought cogito was kinda selected and \n  I got the feeling that Linus wasn't exactly bothered what it was called.\nAnyway, git has a rename that needs testing at some point...\n\n> legit        Since git is GPLv2, but perhaps a little too French.\nThat made me smile.\nQuite a few entendres in there...\n\nIt's Petr's baby - he gets to name it.\n\nDavid\n"},{"id":"1060","messageId":"20050420233453.GC12962@pasky.ji.cz","threadId":"95","inReplyTo":"42655630.80207@dgreaves.com","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-20T23:34:53Z","receivedAt":"2005-04-20T23:34:53Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 19, 2005 at 09:04:16PM CEST, I got a letter\nwhere David Greaves <david@dgreaves.com> told me that...\n> I don't love the 'require gitadd.pl' but it's a gradual start...\n\nI hate it, for one. ;-)\n\n> Cogito.pm seems to be a good place for the library stuff.\n\nSounds sensible.\n\n> git.pl\n> passes everything to scripts except gitadd.pl\n\nWe've decided to go for the individual scripts directly. :-)\n\nUnfortunately, you didn't send the attachments inline, so I can't\ncomment on them sensibly.\n\nPerhaps my main problem is now style. I'd prefer you do format it alike\nthe C sources of git, with 8-chars indentation and such. Also make sure\nyou use spaces around (or after) operators. Also, for just few short\nfunctions I prefer putting the functions before the code itself.\n\n> use IO::File;   # leads to less perlish syntax and is standard in perl dists\n\nOh come on. Are you writing Perl or not? I think it looks pretty awful,\nand you are using Perl filehandle idioms anyway, so...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1112","messageId":"42677284.1010005@dgreaves.com","threadId":"95","inReplyTo":"20050420233453.GC12962@pasky.ji.cz","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-04-21T09:29:40Z","receivedAt":"2005-04-21T09:29:40Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"> We've decided to go for the individual scripts directly. :-)\nJust to clarify - individual scripts or $0 name handling?\n\nI kinda like one big script - also means we don't need to 'install' it \nto get access to Cogito.pm...\n\n> \n> Unfortunately, you didn't send the attachments inline, so I can't\n> comment on them sensibly.\n\nI'm not sure what you want here; last time you said:\n> Thanks. Could you please send the patches signed off and either with\n> content-disposition: inline or in the mail body?\n\nSo I dug around Thunderbird's config and, this time, from my email on \nthe git list:\n--------------050206040606040908050407\nContent-Type: application/x-perl;\n  name=\"gitadd.pl\"\nContent-Transfer-Encoding: 7bit\nContent-Disposition: inline;\n  filename=\"gitadd.pl\"\n\n\n> Perhaps my main problem is now style. I'd prefer you do format it alike\n> the C sources of git, with 8-chars indentation and such. Also make sure\n> you use spaces around (or after) operators. Also, for just few short\n> functions I prefer putting the functions before the code itself.\nwill do\n\n\nDavid\n"},{"id":"1434","messageId":"20050423234101.GP13222@pasky.ji.cz","threadId":"95","inReplyTo":"42677284.1010005@dgreaves.com","subject":"Re: [PATCH] Add help details to git help command. (This time with Perl)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-23T23:41:01Z","receivedAt":"2005-04-23T23:41:01Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Please ignore the reply marker part. ;-)\n\nSorry,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"}]}