{"thread":{"id":"62571","subject":"[BUG] Inconsistent output of git-show","startedAt":"2024-11-29T19:36:10Z","lastAt":"2024-11-29T20:29:01Z","messageCount":2,"participants":["Gabriel Krisman Bertazi","Kristoffer Haugsbakk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"508343","messageId":"87jzclal3s.fsf@mailhost.krisman.be","threadId":"62571","inReplyTo":null,"subject":"[BUG] Inconsistent output of git-show","fromName":"Gabriel Krisman Bertazi","fromEmail":"krisman@suse.de","sentAt":"2024-11-29T19:36:07Z","receivedAt":"2024-11-29T19:36:10Z","isPatch":false,"sender":{"key":"krisman@suse.de","avatar":null},"body":"Hi,\n\n1.  git show --oneline --no-patch\n7af08b57bcb9 (HEAD, origin/master, linus/master) Merge tag 'trace-v6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace\n\n2.  git show --oneline --no-patch | cat\n7af08b57bcb9 Merge tag 'trace-v6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace\n\n(--oneline doesn't matter here. Just making the output concise)\n\nThe branch information in parenthesis vanished just because of the shell\nredirection.  That makes quickly writing shell one-liners very annoying.\nSure, I can go figure a proper git invocation to get me that\ninformation. But we're all hardwired to use basic shell commands, and\nsometimes all I need is a quick grep and not learn a program-specific\nway of filtering.\n\nSo, could we make the output consistent regardless of redirection,\ni.e. What You See Is What You Pipe?  Whoever requires a specific format\nfor a script should be the ones using --format.\n\nI've got v2.47.0 and I admit to not have tested later versions.\n\nThanks,\n\n-- \nGabriel Krisman Bertazi\n"},{"id":"508346","messageId":"2ffaeffe-1f05-4100-8ee8-3c87437297bd@app.fastmail.com","threadId":"62571","inReplyTo":"87jzclal3s.fsf@mailhost.krisman.be","subject":"Re: [BUG] Inconsistent output of git-show","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-11-29T20:26:33Z","receivedAt":"2024-11-29T20:29:01Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"Hi\n\nOn Fri, Nov 29, 2024, at 20:36, Gabriel Krisman Bertazi wrote:\n> Hi,\n>\n> 1.  git show --oneline --no-patch\n> 7af08b57bcb9 (HEAD, origin/master, linus/master) Merge tag 'trace-v6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace\n>\n> 2.  git show --oneline --no-patch | cat 7af08b57bcb9 Merge tag 'trace-v6.13-2' of  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace\n>\n> (--oneline doesn't matter here. Just making the output concise)\n>\n> The branch information in parenthesis vanished just because of the shell\n> redirection.  That makes quickly writing shell one-liners very annoying.\n\nThe narrow fix (of course your point is more general):\n\n    git show --no-patch --oneline --decorate=short | cat\n\nOr set that with `log.decorate` (the default is `auto`, hence this\nisatty behavior).\n\n> Sure, I can go figure a proper git invocation to get me that\n> information. But we're all hardwired to use basic shell commands, and\n> sometimes all I need is a quick grep and not learn a program-specific\n> way of filtering.\n\nAs a list lurker I get the impression that the proper way is to use\nplumbing commands for scripting.[1]  That’s the philosophy at least.\nIn practice I’m not that good at that:\n\n• git-log: replace with git-rev-list\n• git-diff: replace with git-diff-tree\n• git-merge: replace with git-merge-tree\n• git-commit: replace with git-commit-tree\n\nBut I’m far from good enough with all the various tools in the suite.\nSo a git-show here and there will be used.  By me at least.\n\nI also get the impression that this philosophy hasn’t necessarily worked\nout in practice, at least not culturally.\n\nThe resources on the Web are also not great for this purpose.  Because\nwhen I search for Git Plumbing I don’t find scripting resources; I find\na bunch of articles about How To Implement Git With Plumbing.  As if the\ntools were meant to make Git In A Weekend.  That and a handful of\nStackOverflow answers that say “well these bunch of commands marked\n“plumbing” exist.”\n\nTurning to the documentation I haven’t (in my casual experience) seen\nmuch connection being made between the porcelain and the plumbing.\nThere are some hints in git-rev-list like\n\n    rev-list is an essential Git command, since it provides the ability to\n    build and traverse commit ancestry graphs. For this reason, it has a lot\n    of different options that enable it to be used by commands as different\n    as git bisect and git repack.\n\nIt seems natural to start a script with porcelain commands.  Then rewrite\nit in terms of plumbing commands as it matures from a one-off script to\nsomething you just want to call and not fiddle/evolve any further.  But in\nten years I haven’t naturally stumbled upon such a guide (I’ve only been\nsomewhat actively looking lately).\n\nJust my two cents.\n\n> So, could we make the output consistent regardless of redirection,\n> i.e. What You See Is What You Pipe?  Whoever requires a specific format\n> for a script should be the ones using --format.\n>\n> I've got v2.47.0 and I admit to not have tested later versions.\n>\n> Thanks,\n>\n> --\n> Gabriel Krisman Bertazi\n\n† 1: See (from a quick search):\n\n    https://lore.kernel.org/git/xmqqy16ematj.fsf@gitster.g/\n\n    > The other question is why advice is being shown in the first place. In\n    > theory, all one should ever use in scripted usecases are plumbing tools.\n    > And as plumbing tools are explicitly not designed for users, they should\n    > never show advice in the first place. I guess chances are high though\n    > that the scripts in question used porcelain. That is also understandable\n    > though: our plumbing tools are often not as powerful as the porcelain\n    > ones, which has been lamented on the mailing list several times.\n\n    From: https://lore.kernel.org/git/ZsbYYo3pLUAmBU0e@tanuki/\n\n    > The usual answer is \"these tools should be using the low-level\n    > plumbing commands like diff-files, diff-index, and diff-tree\", so I\n    > am not worried about it too much myself, and the above is purely the\n    > devil's advocate comment.\n\n    From: https://lore.kernel.org/git/xmqqedcszhty.fsf@gitster.g/\n\n-- \nKristoffer Haugsbakk\n"}]}