{"thread":{"id":"15176","subject":"About git pretty","startedAt":"2008-08-22T23:24:34Z","lastAt":"2009-02-21T15:31:31Z","messageCount":11,"participants":["Felipe Contreras","Junio C Hamano","Stephan Beyer","David Tweed","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"88230","messageId":"94a0d4530808221624m26034923pbc1f97cb4c4203d8@mail.gmail.com","threadId":"15176","inReplyTo":null,"subject":"About git pretty","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-22T23:24:34Z","receivedAt":"2008-08-22T23:24:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nPlease read aloud the following commands:\ngit log --pretty=short\ngit log --pretty=full\ngit log --pretty=format:%s\n\nIt is just me or 'pretty full' doesn't exactly convey the meaning of\nthe action to execute?\n\nHow about:\ngit log --format=short\ngit log --format=full\ngit log --format=custom:%s\n\nIf you like the idea I can work on a patch.\n\nBest regards.\n\n-- \nFelipe Contreras\n"},{"id":"88235","messageId":"7vd4k062k2.fsf@gitster.siamese.dyndns.org","threadId":"15176","inReplyTo":"94a0d4530808221624m26034923pbc1f97cb4c4203d8@mail.gmail.com","subject":"Re: About git pretty","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-22T23:41:01Z","receivedAt":"2008-08-22T23:41:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Felipe Contreras\" writes:\n\n> Please read aloud the following commands:\n> git log --pretty=short\n> git log --pretty=full\n> git log --pretty=format:%s\n>\n> It is just me or 'pretty full' doesn't exactly convey the meaning of\n> the action to execute?\n>\n> How about:\n> git log --format=short\n> git log --format=full\n> git log --format=custom:%s\n>\n> If you like the idea I can work on a patch.\n\nFWIW, I don't like it.\n"},{"id":"88237","messageId":"20080823000336.GB14684@leksak.fem-net","threadId":"15176","inReplyTo":"94a0d4530808221624m26034923pbc1f97cb4c4203d8@mail.gmail.com","subject":"Re: About git pretty","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-08-23T00:03:37Z","receivedAt":"2008-08-23T00:03:37Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nFelipe Contreras wrote:\n> Hi,\n> \n> Please read aloud the following commands:\n> git log --pretty=short\n> git log --pretty=full\n> git log --pretty=format:%s\n> \n> It is just me or 'pretty full' doesn't exactly convey the meaning of\n> the action to execute?\n\nBut \"pretty short\" and \"pretty format\" is. :)\n\n> How about:\n> git log --format=short\n> git log --format=full\n> git log --format=custom:%s\n> \n> If you like the idea I can work on a patch.\n\nBecause --pretty= is an option taken by many git commands including\ngit plumbing (e.g. rev-list), many scripts will rely on \"--pretty\" and they\nall would have to be changed. And --pretty exists since Jan 2005 (see\n9d97aa64).\n\nAlso, --format is an option available to git-archive and git-for-each-ref\nwith a different intention for each. --pretty exists for several git\ncommands with the same intention for all (I think) -- pretty-printing\ncommit objects.\n\nAnd, btw, I also do not think that your idea does really solve the \n\"problem\" that it always will make sense when you read it aloud.\n\nThus it seems that --format has no benefit over --pretty at all. :-)\n\n\nAhh, another thought:\nIf a new git user is looking for an option to _format_ git-log output,\nshe will surely search the git-log manual page for the word \"format\", finding\n\n 1. --raw\n 2. --shortstat\n 3. --abbrev\n 4. --full-index\n 5. --pretty\n STRIKE!\n\nThis makes me wonder if it could make sense to move --pretty up in the\ngit-log manual page, but I do not think renaming it is worth the\ntrouble.\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"88238","messageId":"e1dab3980808221704h3c713e64n41adc631d7a79601@mail.gmail.com","threadId":"15176","inReplyTo":"7vd4k062k2.fsf@gitster.siamese.dyndns.org","subject":"Re: About git pretty","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-08-23T00:04:09Z","receivedAt":"2008-08-23T00:04:09Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Sat, Aug 23, 2008 at 12:41 AM, Junio C Hamano wrote:\n> \"Felipe Contreras\" writes:\n>> It is just me or 'pretty full' doesn't exactly convey the meaning of\n>> the action to execute?\n[snip]\n>> If you like the idea I can work on a patch.\n>\n> FWIW, I don't like it.\n\nIt's probably much too late to change conventions given the number of\ndeployed scripts, but one of the annoyances for me about git is that a\nlot of the commands/options names are based on what the code does/is\nwritten rather than relating to what a user who doesn't know or care\nabout the inner workings expects as output. For instance, I imagine\nthe --pretty gets its name because a pretty printing routine, called\npretty_print_commit in the code, was written but the name probably\ndoesn't make much sense to anyone who's not from a computer science\nbackground. Likewise the options --hard, --soft and --mixed to git\nreset lack any natural mnemonic structure. (I'm sure one can be\ncontrived, but I doubt it'd be particularly natural.) Then there's\ngit-fsck and gitk.\n\nIt's not remotely a big problem but it is something that I'd imagine\nwould have been done differently with hindsight.\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"},{"id":"88240","messageId":"7v4p5c612y.fsf@gitster.siamese.dyndns.org","threadId":"15176","inReplyTo":"e1dab3980808221704h3c713e64n41adc631d7a79601@mail.gmail.com","subject":"Re: About git pretty","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-23T00:12:53Z","receivedAt":"2008-08-23T00:12:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David Tweed\" writes:\n\n> On Sat, Aug 23, 2008 at 12:41 AM, Junio C Hamano wrote:\n>> \"Felipe Contreras\" writes:\n>>> It is just me or 'pretty full' doesn't exactly convey the meaning of\n>>> the action to execute?\n> [snip]\n>>> If you like the idea I can work on a patch.\n>>\n>> FWIW, I don't like it.\n>\n> It's probably much too late to change conventions given the number of\n> deployed scripts, but one of the annoyances for me about git is that a\n> lot of the commands/options names are based on what the code does/is\n> written rather than relating to what a user who doesn't know or care\n> about the inner workings expects as output. For instance, I imagine\n> the --pretty gets its name because a pretty printing routine, called\n> pretty_print_commit in the code,...\n\nIt's the other way around. We name function pretty_print_commit() because\nwe would want to pretty print out output and the option to trigger the\nbehaviour then is named --pretty.\n"},{"id":"88242","messageId":"e1dab3980808221734l470134d3u62bd708e7baabe0d@mail.gmail.com","threadId":"15176","inReplyTo":"7v4p5c612y.fsf@gitster.siamese.dyndns.org","subject":"Re: About git pretty","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-08-23T00:34:43Z","receivedAt":"2008-08-23T00:34:43Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Sat, Aug 23, 2008 at 1:12 AM, Junio C Hamano wrote:\n> \"David Tweed\" writes:\n>\n>> On Sat, Aug 23, 2008 at 12:41 AM, Junio C Hamano wrote:\n>>> \"Felipe Contreras\" writes:\n>>>> It is just me or 'pretty full' doesn't exactly convey the meaning of\n>>>> the action to execute?\n>> [snip]\n>>>> If you like the idea I can work on a patch.\n>>>\n>>> FWIW, I don't like it.\n>>\n>> It's probably much too late to change conventions given the number of\n>> deployed scripts, but one of the annoyances for me about git is that a\n>> lot of the commands/options names are based on what the code does/is\n>> written rather than relating to what a user who doesn't know or care\n>> about the inner workings expects as output. For instance, I imagine\n>> the --pretty gets its name because a pretty printing routine, called\n>> pretty_print_commit in the code,...\n>\n> It's the other way around. We name function pretty_print_commit() because\n> we would want to pretty print out output and the option to trigger the\n> behaviour then is named --pretty.\n\nThe point I was making is that, to my understanding, pretty-printing\nis the \"standard\" term _programmers_ think of when they're thinking\nabout writing routines for doing sophisticated output formatting. I\ndoubt that anyone who isn't an experienced programmer associates the\nterm \"pretty printing\" naturally with \"configuring output layout\". I\nwas talking about options that would make sense for someone who's not\na hardcore programmer but for whom using git would be beneficial, so I\ndidn't include git-diff for criticism because to be able to use the\noutput you've got to be familiar with the diff program already, and\nhence know the name.\n\n(My undergrad degree was in mathematics and I only slowly picked up\ncomputer jargon as I moved into computer research. Git would have been\nuseful to me long before I happened across some papers on pretty\nprinting, and I ended up learning what fsck in general means from\ntrying to figure out what the hell the faux-swearing you get on the\ninternet was. I could probably have gone on in ignorance of the\nconcept unix people encapsulate with \"fsck\" otherwise.)\n\nMy point is that the terms that come naturally to hardcore programmers\nare opaque to people who might benefit from git.\n\nBeing honest, my only serious issue was with git reset. The about the\nfirst five times I knew the \"operation\" I wanted to perform by\ncarefully checked the man-page because I wasn't sure whether --hard or\n--soft corresponded to the operation I wanted.\n\n\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"},{"id":"88244","messageId":"e1dab3980808221738m495dab8ep95880e6151614a92@mail.gmail.com","threadId":"15176","inReplyTo":"e1dab3980808221734l470134d3u62bd708e7baabe0d@mail.gmail.com","subject":"Re: About git pretty","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-08-23T00:38:31Z","receivedAt":"2008-08-23T00:38:31Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Sat, Aug 23, 2008 at 1:34 AM, David Tweed wrote:\n> Being honest, my only serious issue was with git reset. The about the\n> first five times I knew the \"operation\" I wanted to perform by\n> carefully checked the man-page because I wasn't sure whether --hard or\n> --soft corresponded to the operation I wanted.\n\nIt's too late for me to make sense :-) . An ungarbled final paragraph:\n\nBeing honest, my only serious issue was with git reset. For about\nfirst five times I knew the \"operation\" I wanted to perform but\ncarefully checked the man-page because I wasn't sure whether --hard or\n--soft corresponded to the operation I wanted (and didn't want to take\nany chances of picking the wrong one).\n\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"},{"id":"88304","messageId":"94a0d4530808231157y3d36fc23q4617787214a02ea1@mail.gmail.com","threadId":"15176","inReplyTo":"20080823000336.GB14684@leksak.fem-net","subject":"Re: About git pretty","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-23T18:57:03Z","receivedAt":"2008-08-23T18:57:03Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Aug 23, 2008 at 3:03 AM, Stephan Beyer wrote:\n> Hi,\n>\n> Felipe Contreras wrote:\n>> Hi,\n>>\n>> Please read aloud the following commands:\n>> git log --pretty=short\n>> git log --pretty=full\n>> git log --pretty=format:%s\n>>\n>> It is just me or 'pretty full' doesn't exactly convey the meaning of\n>> the action to execute?\n>\n> But \"pretty short\" and \"pretty format\" is. :)\n>\n>> How about:\n>> git log --format=short\n>> git log --format=full\n>> git log --format=custom:%s\n>>\n>> If you like the idea I can work on a patch.\n>\n> Because --pretty= is an option taken by many git commands including\n> git plumbing (e.g. rev-list), many scripts will rely on \"--pretty\" and they\n> all would have to be changed. And --pretty exists since Jan 2005 (see\n> 9d97aa64).\n\nWell, it might be difficult, but that doesn't mean it should not be\ndone. Just like the 'git-*' removal, there could be a period for\ntransition.\n\n> Also, --format is an option available to git-archive and git-for-each-ref\n> with a different intention for each. --pretty exists for several git\n> commands with the same intention for all (I think) -- pretty-printing\n> commit objects.\n>\n> And, btw, I also do not think that your idea does really solve the\n> \"problem\" that it always will make sense when you read it aloud.\n>\n> Thus it seems that --format has no benefit over --pretty at all. :-)\n\nHeh, it was just one example. My point is that 'format' is more meaningful.\n\n\n\n-- \nFelipe Contreras\n"},{"id":"88372","messageId":"alpine.DEB.1.00.0808241948390.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15176","inReplyTo":"94a0d4530808231157y3d36fc23q4617787214a02ea1@mail.gmail.com","subject":"Re: About git pretty","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-24T17:49:58Z","receivedAt":"2008-08-24T17:49:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 23 Aug 2008, Felipe Contreras wrote:\n\n> On Sat, Aug 23, 2008 at 3:03 AM, Stephan Beyer wrote:\n>\n> > Felipe Contreras wrote:\n> >> Hi,\n> >>\n> >> Please read aloud the following commands:\n> >> git log --pretty=short\n> >> git log --pretty=full\n> >> git log --pretty=format:%s\n> >>\n> >> It is just me or 'pretty full' doesn't exactly convey the meaning of \n> >> the action to execute?\n> >\n> > But \"pretty short\" and \"pretty format\" is. :)\n> >\n> >> How about:\n> >> git log --format=short\n> >> git log --format=full\n> >> git log --format=custom:%s\n> >>\n> >> If you like the idea I can work on a patch.\n> >\n> > Because --pretty= is an option taken by many git commands \n> > including git plumbing (e.g. rev-list), many scripts will rely on \n> > \"--pretty\" and they all would have to be changed. And --pretty exists \n> > since Jan 2005 (see 9d97aa64).\n> \n> Well, it might be difficult, but that doesn't mean it should not be \n> done. Just like the 'git-*' removal, there could be a period for \n> transition.\n\nOf course it could be done. But I do not deem it necessary. In the \nbalance gain/pain it comes out as not worth the hassle on this guy's \ncalculator.\n\nCiao,\nDscho\n"},{"id":"89216","messageId":"7vfxom1n54.fsf@gitster.siamese.dyndns.org","threadId":"15176","inReplyTo":"alpine.DEB.1.00.0808241948390.24820@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: About git pretty","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-30T16:30:15Z","receivedAt":"2008-08-30T16:30:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> On Sat, Aug 23, 2008 at 3:03 AM, Stephan Beyer wrote:\n>>\n>> > Felipe Contreras wrote:\n>> >> Hi,\n>> >>\n>> >> Please read aloud the following commands:\n>> >> git log --pretty=short\n>> >> git log --pretty=full\n>> >> git log --pretty=format:%s\n>> >>\n>> >> It is just me or 'pretty full' doesn't exactly convey the meaning of \n>> >> the action to execute?\n>> >\n>> > But \"pretty short\" and \"pretty format\" is. :)\n>> >\n>> >> How about:\n>> >> git log --format=short\n>> >> git log --format=full\n>> >> git log --format=custom:%s\n>> >>\n>> >> If you like the idea I can work on a patch.\n>> >\n>> > Because --pretty= is an option taken by many git commands \n>> > including git plumbing (e.g. rev-list), many scripts will rely on \n>> > \"--pretty\" and they all would have to be changed. And --pretty exists \n>> > since Jan 2005 (see 9d97aa64).\n>> \n>> Well, it might be difficult, but that doesn't mean it should not be \n>> done. Just like the 'git-*' removal, there could be a period for \n>> transition.\n>\n> Of course it could be done. But I do not deem it necessary. In the \n> balance gain/pain it comes out as not worth the hassle on this guy's \n> calculator.\n\nOn the other hand, as an undocumented synonym without deprecating nor\nconflicting with existing set of options in any way, I do not think it is\nwrong per-se to support something like:\n\n\tgit log --format=short\n git log --format=':%h %s'\n\nin addition to existing --pretty. It should be fairly obvious and trivial\nto make handle_revision_opt() pretend as if the user said --pretty, and\nfor the latter one silently prefix \"tformat\" while doing so.\n\nI won't be doing such a patch myself, though.\n"},{"id":"105726","messageId":"94a0d4530902210731s79ed8996od57619487de0e58f@mail.gmail.com","threadId":"15176","inReplyTo":"7vfxom1n54.fsf@gitster.siamese.dyndns.org","subject":"Re: About git pretty","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-02-21T15:31:31Z","receivedAt":"2009-02-21T15:31:31Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Aug 30, 2008 at 6:30 PM, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n>\n>>> On Sat, Aug 23, 2008 at 3:03 AM, Stephan Beyer wrote:\n>>>\n>>> > Felipe Contreras wrote:\n>>> >> Hi,\n>>> >>\n>>> >> Please read aloud the following commands:\n>>> >> git log --pretty=short\n>>> >> git log --pretty=full\n>>> >> git log --pretty=format:%s\n>>> >>\n>>> >> It is just me or 'pretty full' doesn't exactly convey the meaning of\n>>> >> the action to execute?\n>>> >\n>>> > But \"pretty short\" and \"pretty format\" is. :)\n>>> >\n>>> >> How about:\n>>> >> git log --format=short\n>>> >> git log --format=full\n>>> >> git log --format=custom:%s\n>>> >>\n>>> >> If you like the idea I can work on a patch.\n>>> >\n>>> > Because --pretty= is an option taken by many git commands\n>>> > including git plumbing (e.g. rev-list), many scripts will rely on\n>>> > \"--pretty\" and they all would have to be changed. And --pretty exists\n>>> > since Jan 2005 (see 9d97aa64).\n>>>\n>>> Well, it might be difficult, but that doesn't mean it should not be\n>>> done. Just like the 'git-*' removal, there could be a period for\n>>> transition.\n>>\n>> Of course it could be done.  But I do not deem it necessary.  In the\n>> balance gain/pain it comes out as not worth the hassle on this guy's\n>> calculator.\n>\n> On the other hand, as an undocumented synonym without deprecating nor\n> conflicting with existing set of options in any way, I do not think it is\n> wrong per-se to support something like:\n>\n>        git log --format=short\n>        git log --format=':%h %s'\n>\n> in addition to existing --pretty.  It should be fairly obvious and trivial\n> to make handle_revision_opt() pretend as if the user said --pretty, and\n> for the latter one silently prefix \"tformat\" while doing so.\n>\n> I won't be doing such a patch myself, though.\n\nI've submitted a patch for that.\n\n-- \nFelipe Contreras\n"}]}