{"thread":{"id":"39004","subject":"rev-list pretty format behavior","startedAt":"2015-04-04T23:27:31Z","lastAt":"2015-04-08T17:12:05Z","messageCount":5,"participants":["Oliver Runge","Junio C Hamano","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"259004","messageId":"CAHaCNWJZQRVxp3ponvh3pPEk=sOHGYypyhi1Dc8HX5gkKEBGrQ@mail.gmail.com","threadId":"39004","inReplyTo":null,"subject":"rev-list pretty format behavior","fromName":"Oliver Runge","fromEmail":"oliver.runge@gmail.com","sentAt":"2015-04-04T23:27:31Z","receivedAt":"2015-04-04T23:27:31Z","isPatch":false,"sender":{"key":"oliver.runge@gmail.com","avatar":"https://gravatar.com/avatar/6ec2409b01d78f221b7a152271a60d51249f6548e8d545fe3184bd9fe47d0848?d=mp&s=160"},"body":"Heyup, everybody.\n\nApologies if this turns out to be a duplicate. Gmane seems broken, so\nI couldn't search the archive.\n\nI'm using git version 2.4.0-rc1. The same behavior exists in 2.1.0.\n\nWith git-log it is possible to specify a custom pretty format that\noutputs one line per commit:\n> git log --pretty=format:\"%h ...\" HEAD~3...HEAD\n826aed5 ...\n915e44c ...\n067178e ...\n\nTrying the same with rev-list results in:\n> git rev-list --pretty=format:\"%h ...\" HEAD~3...HEAD\ncommit 826aed50cbb072d8f159e4c8ba0f9bd3df21a234\n826aed5 ...\ncommit 915e44c6357f3bd9d5fa498a201872c4367302d3\n915e44c ...\ncommit 067178ed8a7822e6bc88ad606b707fc33658e6fc\n067178e ...\n\nIs the separate line of \"commit <hash>\" a must for all formats except\n\"oneline\" or a possible bug?\nBased on the git-rev-list man page and git-log, I would expect to be\nable to override the format as described, since it is possible to get\nthe \"commit <hash>\" line for any format by prefixing it with \"commit\n%H\".\n\nThe only way to get similar behaviour is to do something like:\n> git rev-list ... | grep -v '^commit'\nand that's quite hacky.\n\nI looked at the code and the flow in rev-list seems odd to me. The\nheader_prefix is set outside of show_commit(), it is empty for\nformat=oneline, but set to \"commit \" for any other formats. It's then\nprinted inside show_commit() and followed by the (possibly\nabbreviated) hash. So the display logic is split into two places,\nneither of which knows much about the other, both make decisions based\non the pretty format specified.\n\nEven if the behavior is correct, would you agree that this could be\nrefactored a bit, so the output is less stitched together?\nI'd happily try to help refactoring or fixing it, if it is indeed a bug.\n\nThanks for your ears!\n  Oliver\n"},{"id":"259035","messageId":"xmqqlhi6cma5.fsf@gitster.dls.corp.google.com","threadId":"39004","inReplyTo":"CAHaCNWJZQRVxp3ponvh3pPEk=sOHGYypyhi1Dc8HX5gkKEBGrQ@mail.gmail.com","subject":"Re: rev-list pretty format behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-05T21:12:18Z","receivedAt":"2015-04-05T21:12:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Oliver Runge <oliver.runge@gmail.com> writes:\n\n> I'm using git version 2.4.0-rc1. The same behavior exists in 2.1.0.\n>\n> Trying the same with rev-list results in:\n>> git rev-list --pretty=format:\"%h ...\" HEAD~3...HEAD\n> commit 826aed50cbb072d8f159e4c8ba0f9bd3df21a234\n> 826aed5 ...\n> commit 915e44c6357f3bd9d5fa498a201872c4367302d3\n> 915e44c ...\n> commit 067178ed8a7822e6bc88ad606b707fc33658e6fc\n> 067178e ...\n\nThis is very much the designed behaviour, I would think.  IIRC, the\nuser-format support of \"rev-list\" was designed so that the scripts\ncan customize the output from \"rev-list -v\", which was how scripts\nwere expected to read various pieces of information for each commit\noriginally.  And the 40-hex commit object name and/or a line that\nbegins with \"commit ...\" when a user format is used are meant to\nserve as stable record separator (in that sense, having %H or %h in\nthe userformat given to rev-list is redundant) when these scripts\nare reading output from \"rev-list\".\n\nA new option to tell \"rev-list\" that \"I am designing an output that\nis a-line-per-commit with the userformat and do not need the default\nrecord separator\" or \"I will arrange record separator myself\" would\nbe an acceptable thing to add, provided if many scripts yet to be\nwritten would benefit from such a feature, though.\n"},{"id":"259053","messageId":"CAHaCNWJ+S7Qa0=x2Xo2+HMQa0jz_tT8G+Wp1ugB4UHwBfOZRTg@mail.gmail.com","threadId":"39004","inReplyTo":"xmqqlhi6cma5.fsf@gitster.dls.corp.google.com","subject":"Re: rev-list pretty format behavior","fromName":"Oliver Runge","fromEmail":"oliver.runge@gmail.com","sentAt":"2015-04-06T11:05:20Z","receivedAt":"2015-04-06T11:05:20Z","isPatch":false,"sender":{"key":"oliver.runge@gmail.com","avatar":"https://gravatar.com/avatar/6ec2409b01d78f221b7a152271a60d51249f6548e8d545fe3184bd9fe47d0848?d=mp&s=160"},"body":"Hallo, Mr. Hamano.\n\nThank you for your quick and detailed response.\n\nOn 5 April 2015 at 23:12, Junio C Hamano <gitster@pobox.com> wrote:\n> This is very much the designed behaviour, I would think.  IIRC, the\n> user-format support of \"rev-list\" was designed so that the scripts\n> can customize the output from \"rev-list -v\", which was how scripts\n> were expected to read various pieces of information for each commit\n> originally.  And the 40-hex commit object name and/or a line that\n> begins with \"commit ...\" when a user format is used are meant to\n> serve as stable record separator (in that sense, having %H or %h in\n> the userformat given to rev-list is redundant) when these scripts\n> are reading output from \"rev-list\".\n\nI see, but then I find it even stranger, because \"rev-list -v\" without\n\"pretty\" parameter will only output the hash as separator and \"commit\n<sha1>\" is only introduced if a \"pretty\" parameter other than\n\"oneline\" is specified. The docu states the formating is intended to\nmake \"git rev-list\" behave more like \"git log\", and apart from the\npretty settings \"email\" and \"format\"/\"tformat\" (which don't have\n\"commit <sha1>\" in \"git log\") the formating works exactly like it does\nin \"git log\".\n\ndocu:\n------------------------------------------\nCommit Formatting\n       Using these options, git-rev-list(1) will act similar to the more\n       specialized family of commit log tools: git-log(1), git-show(1),\n       and git-whatchanged(1)\n------------------------------------------\nand\n------------------------------------------\n- format:<string>\nThe format:<string> format allows you to specify which information you\nwant to show. It works a little bit like printf format, with the\nnotable exception that you get a newline with %n instead of \\n.\nE.g, format:\"The author of %h was %an, %ar%nThe title was >>%s<<%n\"\nwould show something like this:\n\n    The author of fe6e0ee was Junio C Hamano, 23 hours ago\n    The title was >>t4119: test autocomputing -p<n> for traditional\ndiff input.<<\n------------------------------------------\n\n> A new option to tell \"rev-list\" that \"I am designing an output that\n> is a-line-per-commit with the userformat and do not need the default\n> record separator\" or \"I will arrange record separator myself\" would\n> be an acceptable thing to add, provided if many scripts yet to be\n> written would benefit from such a feature, though.\n\nI searched github for usages of \"git rev-list --pretty=format\" to see\nwhether I'm alone. I realize this is merely anecdotal, but perhaps\nstill useful.\n\nScripts ignoring the separator:\n------------------------------------------\n# no idea why it always prints those commit lines\ngit rev-list --pretty=format:\" - %s\" \"$@\" |grep -v ^commit\n------------------------------------------\n\n------------------------------------------\ngit rev-list --pretty=format:\"%H %h|%an:%s\" \"$@\" | sed -n\n\"s/^\\([0-9a-f]\\{40\\}\\) \\(.*\\)$/n\\1 [$shape label=\\\"{\\2}\\\"]/p\"\n------------------------------------------\n\n(shortened with \"...\" by me)\n------------------------------------------\ngit rev-list --pretty=format:\"%H %h %d\" \"$@\" | awk '\n...\n!/^commit/ {\n...\n}'\n------------------------------------------\n\nMost of the scripts I found hack around the \"commit <sha1>\" lines,\nmostly in a way that would still work if the lines suddenly weren't\nthere anymore. But unfortunately there are also some examples that\nwould break:\n------------------------------------------\ngit rev-list --oneline --pretty=format:\"%C(yellow)%h\n%C(red)%ad%C(green)%d %C(reset)%s%C(cyan) [%cn]\" --date=short\nHEAD~2..HEAD | awk 'NR % 2 == 0'\n------------------------------------------\n\nAnd finally there are a few that really use the current behavior:\n------------------------------------------\n# tcl\nset revisions [$::versioned_interpreter git rev-list\n\"--pretty=format:%at%n%an <%ae>%n%s\" -n 10 $revision]\nset result {}\nforeach {commit date author summary} [split $revisions \\n] {\n    lappend result [list [lindex $commit 1] $date $author $summary]\n}\n------------------------------------------\n\n(shortened with \"...\" by me)\n------------------------------------------\nsave()\n{\n    awk '{print $2 \" '$1'\" }' | sort >$R/sha/$1\n}\n...\nmake_sha()\n{\n    git rev-list --pretty=format: ^Research-V6 BSD-1 | save BSD-1\n    git rev-list --pretty=format: ^BSD-1 BSD-2 | save BSD-2\n    ...\n}\n------------------------------------------\n\nI really feel that it should be the default behavior for \"format\",\nsince the separator intention isn't described in the docu and isn't\nreally needed for scripts that want to provide their own formating.\nThat being said, I understand that that's likely not going to happen,\nespecially since it would break quite a few legacy scripts.\n\nBut it would be prudent to update the docu to highlight the different\nbehavior for the pretty settings \"email\" and \"format\"/\"tformat\", and\neven though I think another feature to turn off the separator lines\nmakes the command more complex, the fact that so many scripts seem to\nwrite around the behavior might justify it.\n\nI'd like to help with both tasks, if you think they are reasonable.\n\nOliver\n"},{"id":"259129","messageId":"5523E175.2060607@drmicha.warpmail.net","threadId":"39004","inReplyTo":"CAHaCNWJ+S7Qa0=x2Xo2+HMQa0jz_tT8G+Wp1ugB4UHwBfOZRTg@mail.gmail.com","subject":"Re: rev-list pretty format behavior","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-07T13:53:57Z","receivedAt":"2015-04-07T13:53:57Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Oliver Runge venit, vidit, dixit 06.04.2015 13:05:\n> Hallo, Mr. Hamano.\n> \n> Thank you for your quick and detailed response.\n> \n> On 5 April 2015 at 23:12, Junio C Hamano <gitster@pobox.com> wrote:\n>> This is very much the designed behaviour, I would think.  IIRC, the\n>> user-format support of \"rev-list\" was designed so that the scripts\n>> can customize the output from \"rev-list -v\", which was how scripts\n>> were expected to read various pieces of information for each commit\n>> originally.  And the 40-hex commit object name and/or a line that\n>> begins with \"commit ...\" when a user format is used are meant to\n>> serve as stable record separator (in that sense, having %H or %h in\n>> the userformat given to rev-list is redundant) when these scripts\n>> are reading output from \"rev-list\".\n> \n> I see, but then I find it even stranger, because \"rev-list -v\" without\n> \"pretty\" parameter will only output the hash as separator and \"commit\n> <sha1>\" is only introduced if a \"pretty\" parameter other than\n> \"oneline\" is specified. The docu states the formating is intended to\n> make \"git rev-list\" behave more like \"git log\", and apart from the\n> pretty settings \"email\" and \"format\"/\"tformat\" (which don't have\n> \"commit <sha1>\" in \"git log\") the formating works exactly like it does\n> in \"git log\".\n> \n> docu:\n> ------------------------------------------\n> Commit Formatting\n>        Using these options, git-rev-list(1) will act similar to the more\n>        specialized family of commit log tools: git-log(1), git-show(1),\n>        and git-whatchanged(1)\n> ------------------------------------------\n> and\n> ------------------------------------------\n> - format:<string>\n> The format:<string> format allows you to specify which information you\n> want to show. It works a little bit like printf format, with the\n> notable exception that you get a newline with %n instead of \\n.\n> E.g, format:\"The author of %h was %an, %ar%nThe title was >>%s<<%n\"\n> would show something like this:\n> \n>     The author of fe6e0ee was Junio C Hamano, 23 hours ago\n>     The title was >>t4119: test autocomputing -p<n> for traditional\n> diff input.<<\n> ------------------------------------------\n> \n>> A new option to tell \"rev-list\" that \"I am designing an output that\n>> is a-line-per-commit with the userformat and do not need the default\n>> record separator\" or \"I will arrange record separator myself\" would\n>> be an acceptable thing to add, provided if many scripts yet to be\n>> written would benefit from such a feature, though.\n> \n> I searched github for usages of \"git rev-list --pretty=format\" to see\n> whether I'm alone. I realize this is merely anecdotal, but perhaps\n> still useful.\n> \n> Scripts ignoring the separator:\n> ------------------------------------------\n> # no idea why it always prints those commit lines\n> git rev-list --pretty=format:\" - %s\" \"$@\" |grep -v ^commit\n> ------------------------------------------\n> \n> ------------------------------------------\n> git rev-list --pretty=format:\"%H %h|%an:%s\" \"$@\" | sed -n\n> \"s/^\\([0-9a-f]\\{40\\}\\) \\(.*\\)$/n\\1 [$shape label=\\\"{\\2}\\\"]/p\"\n> ------------------------------------------\n> \n> (shortened with \"...\" by me)\n> ------------------------------------------\n> git rev-list --pretty=format:\"%H %h %d\" \"$@\" | awk '\n> ...\n> !/^commit/ {\n> ...\n> }'\n> ------------------------------------------\n> \n> Most of the scripts I found hack around the \"commit <sha1>\" lines,\n> mostly in a way that would still work if the lines suddenly weren't\n> there anymore. But unfortunately there are also some examples that\n> would break:\n> ------------------------------------------\n> git rev-list --oneline --pretty=format:\"%C(yellow)%h\n> %C(red)%ad%C(green)%d %C(reset)%s%C(cyan) [%cn]\" --date=short\n> HEAD~2..HEAD | awk 'NR % 2 == 0'\n> ------------------------------------------\n> \n> And finally there are a few that really use the current behavior:\n> ------------------------------------------\n> # tcl\n> set revisions [$::versioned_interpreter git rev-list\n> \"--pretty=format:%at%n%an <%ae>%n%s\" -n 10 $revision]\n> set result {}\n> foreach {commit date author summary} [split $revisions \\n] {\n>     lappend result [list [lindex $commit 1] $date $author $summary]\n> }\n> ------------------------------------------\n> \n> (shortened with \"...\" by me)\n> ------------------------------------------\n> save()\n> {\n>     awk '{print $2 \" '$1'\" }' | sort >$R/sha/$1\n> }\n> ...\n> make_sha()\n> {\n>     git rev-list --pretty=format: ^Research-V6 BSD-1 | save BSD-1\n>     git rev-list --pretty=format: ^BSD-1 BSD-2 | save BSD-2\n>     ...\n> }\n> ------------------------------------------\n> \n> I really feel that it should be the default behavior for \"format\",\n> since the separator intention isn't described in the docu and isn't\n> really needed for scripts that want to provide their own formating.\n> That being said, I understand that that's likely not going to happen,\n> especially since it would break quite a few legacy scripts.\n> \n> But it would be prudent to update the docu to highlight the different\n> behavior for the pretty settings \"email\" and \"format\"/\"tformat\", and\n> even though I think another feature to turn off the separator lines\n> makes the command more complex, the fact that so many scripts seem to\n> write around the behavior might justify it.\n> \n> I'd like to help with both tasks, if you think they are reasonable.\n> \n> Oliver\n> \n\nI'm wondering what the difference is - or should be - between \"git log\"\nand \"git rev-list\" with (completely) user specified output. That\nquestion goes both ways:\n\n- Why do we need \"rev-list\" to have completely flexible output when we\nhave \"log\" with such flexibility?\n\n- Why do we even have pretty formats for \"rev-list\"?\n\nI'm thinking of rev-list as a raw (plumbing) revision lister much like\ncat-file is the inspection tool for the objects, and log as the human\nfacing output with appropriate defaults (resp. show).\n\nNote that \"rev-list -v\" isn't even documented afaics.\n\nMichael\n"},{"id":"259180","messageId":"CAHaCNWKYY_5JvuAk76wnrTTBaBQM2Fv8hz37tEYC5Jzm1tY-RQ@mail.gmail.com","threadId":"39004","inReplyTo":"5523E175.2060607@drmicha.warpmail.net","subject":"Re: rev-list pretty format behavior","fromName":"Oliver Runge","fromEmail":"oliver.runge@gmail.com","sentAt":"2015-04-08T17:12:05Z","receivedAt":"2015-04-08T17:12:05Z","isPatch":false,"sender":{"key":"oliver.runge@gmail.com","avatar":"https://gravatar.com/avatar/6ec2409b01d78f221b7a152271a60d51249f6548e8d545fe3184bd9fe47d0848?d=mp&s=160"},"body":"Heyup, Dr. Gruber.\n\nOn 7 April 2015 at 15:53, Michael J Gruber <git@drmicha.warpmail.net> wrote:\n> I'm wondering what the difference is - or should be - between \"git log\"\n> and \"git rev-list\" with (completely) user specified output. That\n> question goes both ways:\n>\n> - Why do we need \"rev-list\" to have completely flexible output when we\n> have \"log\" with such flexibility?\n>\n> - Why do we even have pretty formats for \"rev-list\"?\n>\n> I'm thinking of rev-list as a raw (plumbing) revision lister much like\n> cat-file is the inspection tool for the objects, and log as the human\n> facing output with appropriate defaults (resp. show).\n>\n> Note that \"rev-list -v\" isn't even documented afaics.\n\nI can't answer your questions, because I don't have a very deep\nunderstanding of either command, but according to the \"log\" docu,\nformating really belongs to \"rev-list\" and \"log\" only adds the diff-*\nfeatures:\n------------------------------------------\nThe command takes options applicable to the git rev-list command\nto control what is shown and how, and options applicable to the\ngit diff-* commands to control how the changes each commit\nintroduces are shown.\n------------------------------------------\n\nI also feel that perhaps \"pretty\" is a bit of a misnomer and naturally\nis associated with \"human readable\", but the formating is vital for\nany raw output that scripts can process.\n\nOliver\n"}]}