Agreed, ls-tree when called with no arguments was the main use case I wrote this for; the rest was mostly because other commands allow greater ambiguity and I wanted to make the syntax consistent. I don't mind doing this for rev-list as well if that's a useful feature. On 07/03/2018 06:55 PM, Elijah Newren wrote: > On Tue, Jul 3, 2018 at 3:05 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Elijah Newren <newren@xxxxxxxxx> writes: >> >>> On Mon, Jul 2, 2018 at 8:58 PM, Joshua Nelson <jyn514@xxxxxxxxx> wrote: >>>> use syntax similar to `git-checkout` to make <tree-ish> optional for >>>> `ls-tree`. if <tree-ish> is omitted, default to HEAD. infer arguments as >>>> follows: >>>> >>>> 1. if args start with -- >>>> assume <tree-ish> to be HEAD >>>> 2. if exactly one arg precedes --, treat the argument as <tree-ish> >>>> 3. if more than one arg precedes --, exit with an error >>>> 4. if -- is not in args >>>> a) if args[0] is a valid <tree-ish> object, treat is as such >>>> b) else, assume <tree-ish> to be HEAD >>>> >>>> in all cases, every argument besides <tree-ish> is treated as a <path> >>> Cool, this is something I've wanted a few times. >> Hmph, is it, and why? > Default <tree-ish> of HEAD when nothing is specified is certainly > something I wanted. To be honest, I wanted it for rev-list too. > Despite dozens if not hundreds of times of typing 'git ls-tree -r' or > 'git rev-list' expecting to see the results for HEAD (just as git log > does), and getting git's error message reminding me that I need to > specify HEAD, I can't seem to get it through my head to remember that > I need to specify it. > >> I'd prefer *not* to have such a DWIM in a command like ls-tree, aka >> plumbing commands, where predictability is worth 1000 times more >> than ease of typing. > Fair enough. However, what if no <tree-ish> or <path> are specified, > though -- would you be okay with the HEAD being assumed instead of > erroring out in that case?
