{"thread":{"id":"47754","subject":"Missing git options","startedAt":"2018-02-05T09:12:13Z","lastAt":"2018-02-06T18:28:33Z","messageCount":8,"participants":["Martin Häcker","Stefan Beller","Junio C Hamano","Ævar Arnfjörð Bjarmason","brian m. carlson","Duy Nguyen","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"338182","messageId":"AD196D8E-04DB-4274-ADEB-D914A79628B3@schwarz-online.org","threadId":"47754","inReplyTo":null,"subject":"Missing git options","fromName":"Martin Häcker","fromEmail":"mhaecker@schwarz-online.org","sentAt":"2018-02-05T09:12:05Z","receivedAt":"2018-02-05T09:12:13Z","isPatch":false,"sender":{"key":"mhaecker@schwarz-online.org","avatar":null},"body":"Hi there,\n\nI just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.\n\nThis seems something that should be relatively easy to fix.\n\nWhat I’m most missing is\n\n— snip —\n[log]\n\tgraph = true\n\tpatch = true\n— snap —\n\nwhich would / should correspond to `git log —graph —patch`.\n\nWhat do you guys think?\n\nBest Regards,\nMartin Häcker\n"},{"id":"338229","messageId":"CAGZ79kaSY=j23Nn+UH5DGJCptTow7ZpEko2DFzuuAgN2e1BxSQ@mail.gmail.com","threadId":"47754","inReplyTo":"AD196D8E-04DB-4274-ADEB-D914A79628B3@schwarz-online.org","subject":"Re: Missing git options","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-02-05T18:56:17Z","receivedAt":"2018-02-05T18:56:40Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Feb 5, 2018 at 1:12 AM, Martin Häcker\n wrote:\n> Hi there,\n>\n> I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.\n>\n> This seems something that should be relatively easy to fix.\n>\n> What I’m most missing is\n>\n> — snip —\n> [log]\n> graph = true\n> patch = true\n> — snap —\n>\n> which would / should correspond to `git log —graph —patch`.\n>\n> What do you guys think?\n\nFeel free to send patches adding these options.\n\nI had the impression that git-log was a pseudo-plumbing,\ndespite it being explicitly marked porcelain\nas there is no good plumbing alternative.\nBut as we already have things like log.date, log.decorate,\nthat change the output of git-log, I think a patch or graph\noption would be ok.\n\nThanks,\nStefan\n"},{"id":"338236","messageId":"xmqqzi4n9qbl.fsf@gitster-ct.c.googlers.com","threadId":"47754","inReplyTo":"CAGZ79kaSY=j23Nn+UH5DGJCptTow7ZpEko2DFzuuAgN2e1BxSQ@mail.gmail.com","subject":"Re: Missing git options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-02-05T19:41:50Z","receivedAt":"2018-02-05T19:41:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> I had the impression that git-log was a pseudo-plumbing,\n> despite it being explicitly marked porcelain\n> as there is no good plumbing alternative.\n\nI do not think that is a fair assessment of the situation. The more\ntroublesome is that depending on what exactly you want to do, you\nneed to use a different plumbing command and/or combinations of\nthem, which means people need to _learn_ Git scripting. \n\nWe recently saw that somebody used \"log -1 --pretty=format:%T\n$commit\" when the code only needed to say \"rev-parse --verify\n$commit^{tree}\" and got broken due to end-user configuration ;-)\n\n"},{"id":"338244","messageId":"87tvuvkxhz.fsf@evledraar.gmail.com","threadId":"47754","inReplyTo":"AD196D8E-04DB-4274-ADEB-D914A79628B3@schwarz-online.org","subject":"Re: Missing git options","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-02-05T20:11:20Z","receivedAt":"2018-02-05T20:11:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Feb 05 2018, Martin Häcker jotted:\n\n> Hi there,\n>\n> I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.\n>\n> This seems something that should be relatively easy to fix.\n>\n> What I’m most missing is\n>\n> — snip —\n> [log]\n> \tgraph = true\n> \tpatch = true\n> — snap —\n>\n> which would / should correspond to `git log —graph —patch`.\n>\n> What do you guys think?\n\nFWIW my WIP\nhttps://public-inbox.org/git/20170328131316.32516-1-avarab@gmail.com/\nhad some discussion around this.\n\n"},{"id":"338462","messageId":"20180206004313.GC7904@genre.crustytoothpaste.net","threadId":"47754","inReplyTo":"AD196D8E-04DB-4274-ADEB-D914A79628B3@schwarz-online.org","subject":"Re: Missing git options","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-02-06T00:43:13Z","receivedAt":"2018-02-06T00:43:24Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Feb 05, 2018 at 10:12:05AM +0100, Martin Häcker wrote:\n> Hi there,\n> \n> I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.\n> \n> This seems something that should be relatively easy to fix.\n> \n> What I’m most missing is\n> \n> — snip —\n> [log]\n> \tgraph = true\n> \tpatch = true\n> — snap —\n> \n> which would / should correspond to `git log —graph —patch`.\n> \n> What do you guys think?\n\nI think this is likely to cause problems. Many people use git log with\n--pretty to format commit hashes or messages into other programs. I'm\naware of multiple tools that will simply break if --graph or --patch\nbecome the default. Requiring people to retrofit their tools to use\n--no-graph or --no-patch is likely to be a burden.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\nhttps://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"338498","messageId":"C6AF93BC-048F-4944-AB87-36AC2A5C5466@schwarz-online.org","threadId":"47754","inReplyTo":"20180206004313.GC7904@genre.crustytoothpaste.net","subject":"Re: Missing git options","fromName":"Martin Häcker","fromEmail":"mhaecker@schwarz-online.org","sentAt":"2018-02-06T11:13:12Z","receivedAt":"2018-02-06T11:13:20Z","isPatch":false,"sender":{"key":"mhaecker@schwarz-online.org","avatar":null},"body":"Hi all,\n\n> Am 06.02.2018 um 01:43 schrieb brian m. carlson :\n> \n> I think this is likely to cause problems. Many people use git log with\n> --pretty to format commit hashes or messages into other programs. I'm\n> aware of multiple tools that will simply break if --graph or --patch\n> become the default. Requiring people to retrofit their tools to use\n> --no-graph or --no-patch is likely to be a burden.\n\nWhile I share your concern, this is something that will completely freeze development of the git tui which I cannot imagine is wanted.\n\nIf this where my tool, I would much rather advertise an output format specifically for scripting.\n\nAn interim solution could be something like an `—ignore-configuration` option that allows script writers to get predictable output. This however still freezes the default output of git forever.\n\nSo you will need something like —output-for=scripting|json|xml|whatever sooner or later. Mixing up the TUI for humans and for scripts is not going to be fun to evolve.\n\nBest Regards,\nMartin Häcker\n\n"},{"id":"338500","messageId":"CACsJy8DcG5bKdo=PkQnbtaZF6m_ngC+WRkmiUzMhsrxokPQmcA@mail.gmail.com","threadId":"47754","inReplyTo":"C6AF93BC-048F-4944-AB87-36AC2A5C5466@schwarz-online.org","subject":"Re: Missing git options","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-02-06T11:47:19Z","receivedAt":"2018-02-06T11:47:55Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 6, 2018 at 6:13 PM, Martin Häcker\n wrote:\n> This however still freezes the default output of git forever.\n\nWhy is that a bad thing? Default output format should not change\n(much) from version to version, or from machine to machine (because of\ndifferent ~/.gitconfig) for that matter. I don't want to type \"git\nlog\" on somebody else's machine and have a big surprise. You _can_\ncustomize output but that should be explicit.\n\nIf you want good defaults, that's what aliases are for. I personally\nrarely type \"git log\". I have \"l\", \"lp\", \"l1\" and other aliases for\nmy everyday use.\n-- \nDuy\n"},{"id":"338527","messageId":"20180206182755.GD104086@aiede.svl.corp.google.com","threadId":"47754","inReplyTo":"C6AF93BC-048F-4944-AB87-36AC2A5C5466@schwarz-online.org","subject":"Re: Missing git options","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-02-06T18:27:55Z","receivedAt":"2018-02-06T18:28:33Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMartin Häcker wrote:\n>> Am 06.02.2018 um 01:43 schrieb brian m. carlson :\n\n>> I think this is likely to cause problems. Many people use git log with\n>> --pretty to format commit hashes or messages into other programs. I'm\n>> aware of multiple tools that will simply break if --graph or --patch\n>> become the default. Requiring people to retrofit their tools to use\n>> --no-graph or --no-patch is likely to be a burden.\n>\n> While I share your concern, this is something that will completely\n> freeze development of the git tui which I cannot imagine is wanted.\n\nOn the contrary, we take things on a case by case basis. Brian\ndescribed a cost to your proposed change and you described a benefit;\nthe next step would be to figure out a way to accomplish what you're\naiming to do in a way that maximizes the benefit and minimizes the\ncost.\n\nIn other words, it is not that we never change default output formats,\nbut we do care a lot about helping existing users. One way of doing\nthat is to provide more convenient machine-readable versions of some\ncommands so that it is obvious to script writers what to use.\n\nAs Stefan Beller mentioned, \"git log\" is in interesting case, in that\nthe scripting commands exist:\n\n - \"git rev-list\" to list commits satisfying some criteria\n - \"git diff-tree --stdin\" to show information about those commits\n\nBut these commands were not sufficiently discoverable and easy to use,\nso people end up using \"git log\" for scripting anyway. We provide\n\n - \"git log --format\" to produce log output with a fixed format, and\n in particular\n\n - \"git log --format=raw\" to print raw objects\n\nIt's perfectly normal and common to change what \"git log\n--format=medium\" (the default format) prints, as long as we take into\naccount the effect on existing users. In particular:\n\n - Some scripts do not care about the *exact* format from \"git log\"\n but are using the output for a particular purpose (e.g. to generate\n release notes that they distribute along with compiler output).\n If these scripts start _sometimes_ using --graph instead based on\n configuration, this would be disruptive to some users.\n\n - Making --format suppress `log.graph` configuration feels confusing\n and hard to explain to me. --graph --format= would mean something\n different from -c log.graph=true --format=, except when =\n medium, or \"--format=medium\" would mean something different from not\n specifying --format at all even though medium is the default format.\n\nIn that context, it feels simpler to me to use aliases:\n\n\t[alias]\n\t\tl = log --oneline --graph --patch\n\nThat way, it does not confuse scripts, and even better, it is easier\nto type, as \"git l\".\n\nI would be happy to see some documentation pointing users to the\nalias feature for this purpose.\n\nAs an example of changing the default \"git log\" format, see the\nhistory in \"git log --grep=decorate\". I am all for that kind of\nchange, but I don't think --graph or --patch falls into this category.\n\nThanks and hope that helps,\nJonathan\n"}]}