Re: [PATCH] ls-tree: default <tree-ish> to HEAD

[Taylor Blau <me@ttaylorr.com>]

On Mon, Aug 07, 2023 at 09:25:57AM -0700, Junio C Hamano wrote:
> "Ryan Williams via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Ryan Williams <ryan@runsascoded.com>
> >
> > When no positional arguments are passed to `git ls-tree`, it currently
> > prints "usage" info to stderr and exits with code 129. A more intuitive
> > default would be to operate on the `HEAD` commit's tree (similarly to
> > `git show`, `git log`, and possibly others).
>
> As 'ls-tree' is a plumbing command meant for script writers, it was
> designed to require the users to be more explicit.  So, similarity
> to "show" and other Porcelain commands do not weigh much here.  Same
> for "rev-list" that does not fall back to HEAD.
>
> This was a very deliberate design decision to help use of the
> plumbing commands.  A buggy script may say
>
>     TREE=$(some command to find a tree object)
>     git ls-tree $TREE
>
> without making sure something sensible is in $TREE (and not even
> quoting it like "$TREE"), and if ls-tree defaulted to something, the
> script will silently produce a wrong result, instead of failing,
> robbing the script writer a chance to notice a bug in their code to
> come up with the TREE object name.

Yeah, I am similarly torn. On one hand, I think that it is true that
people use ls-tree for various tasks more than we'd expect from a
typical plumbing command (but less than a porcelain one, to be sure).

So in that sense I am inclined to agree with Ryan that their suggestion
is a good one. ...But, I think even more important than that is avoiding
buggy invocations like the kind you describe above that would produce
subtly wrong results.

I think you could make an argument that you could implement that
behavior and also emit a warning() when tree-ish is blank and the output
isn't going to a TTY. But that seems kind of gross to me, so I'd just as
soon not change the existing behavior here.

Thanks,
Taylor