On Mon, Aug 07, 2023 at 09:25:57AM -0700, Junio C Hamano wrote: > "Ryan Williams via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Ryan Williams <ryan@xxxxxxxxxxxxxxx> > > > > 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
