* Re: [BUG] Inconsistent output of git-show
2024-11-29 19:36 [BUG] Inconsistent output of git-show Gabriel Krisman Bertazi
@ 2024-11-29 20:26 ` Kristoffer Haugsbakk
0 siblings, 0 replies; 2+ messages in thread
From: Kristoffer Haugsbakk @ 2024-11-29 20:26 UTC (permalink / raw)
To: Gabriel Krisman Bertazi, git
Hi
On Fri, Nov 29, 2024, at 20:36, Gabriel Krisman Bertazi wrote:
> Hi,
>
> 1. git show --oneline --no-patch
> 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
>
> 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
>
> (--oneline doesn't matter here. Just making the output concise)
>
> The branch information in parenthesis vanished just because of the shell
> redirection. That makes quickly writing shell one-liners very annoying.
The narrow fix (of course your point is more general):
git show --no-patch --oneline --decorate=short | cat
Or set that with `log.decorate` (the default is `auto`, hence this
isatty behavior).
> Sure, I can go figure a proper git invocation to get me that
> information. But we're all hardwired to use basic shell commands, and
> sometimes all I need is a quick grep and not learn a program-specific
> way of filtering.
As a list lurker I get the impression that the proper way is to use
plumbing commands for scripting.[1] That’s the philosophy at least.
In practice I’m not that good at that:
• git-log: replace with git-rev-list
• git-diff: replace with git-diff-tree
• git-merge: replace with git-merge-tree
• git-commit: replace with git-commit-tree
But I’m far from good enough with all the various tools in the suite.
So a git-show here and there will be used. By me at least.
I also get the impression that this philosophy hasn’t necessarily worked
out in practice, at least not culturally.
The resources on the Web are also not great for this purpose. Because
when I search for Git Plumbing I don’t find scripting resources; I find
a bunch of articles about How To Implement Git With Plumbing. As if the
tools were meant to make Git In A Weekend. That and a handful of
StackOverflow answers that say “well these bunch of commands marked
“plumbing” exist.”
Turning to the documentation I haven’t (in my casual experience) seen
much connection being made between the porcelain and the plumbing.
There are some hints in git-rev-list like
rev-list is an essential Git command, since it provides the ability to
build and traverse commit ancestry graphs. For this reason, it has a lot
of different options that enable it to be used by commands as different
as git bisect and git repack.
It seems natural to start a script with porcelain commands. Then rewrite
it in terms of plumbing commands as it matures from a one-off script to
something you just want to call and not fiddle/evolve any further. But in
ten years I haven’t naturally stumbled upon such a guide (I’ve only been
somewhat actively looking lately).
Just my two cents.
> So, could we make the output consistent regardless of redirection,
> i.e. What You See Is What You Pipe? Whoever requires a specific format
> for a script should be the ones using --format.
>
> I've got v2.47.0 and I admit to not have tested later versions.
>
> Thanks,
>
> --
> Gabriel Krisman Bertazi
† 1: See (from a quick search):
https://lore.kernel.org/git/xmqqy16ematj.fsf@gitster.g/
> The other question is why advice is being shown in the first place. In
> theory, all one should ever use in scripted usecases are plumbing tools.
> And as plumbing tools are explicitly not designed for users, they should
> never show advice in the first place. I guess chances are high though
> that the scripts in question used porcelain. That is also understandable
> though: our plumbing tools are often not as powerful as the porcelain
> ones, which has been lamented on the mailing list several times.
From: https://lore.kernel.org/git/ZsbYYo3pLUAmBU0e@tanuki/
> The usual answer is "these tools should be using the low-level
> plumbing commands like diff-files, diff-index, and diff-tree", so I
> am not worried about it too much myself, and the above is purely the
> devil's advocate comment.
From: https://lore.kernel.org/git/xmqqedcszhty.fsf@gitster.g/
--
Kristoffer Haugsbakk
^ permalink raw reply [flat|nested] 2+ messages in thread