Re: [PATCH 1/3] ls-tree.c: support `--oid-only` option for "git-ls-tree"
- From
Jeff King <peff@peff.net>
- Date
- Nov 15, 2021, 19:25 UTC
- Message-ID
- <YZK0MKCYAJmG+pSU@coredump.intra.peff.net>
- In-Reply-To
- <YZKyC7c8b9PnyXG8@coredump.intra.peff.net>
On Mon, Nov 15, 2021 at 02:16:27PM -0500, Jeff King wrote:
Show 24 quoted lines
> On Mon, Nov 15, 2021 at 07:51:51PM +0800, Teng Long wrote:
>
> > diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
> > index 3a442631c7..1f82229649 100644
> > --- a/builtin/ls-tree.c
> > +++ b/builtin/ls-tree.c
> > @@ -20,6 +20,7 @@ static int line_termination = '\n';
> > #define LS_SHOW_TREES 4
> > #define LS_NAME_ONLY 8
> > #define LS_SHOW_SIZE 16
> > +#define LS_OID_ONLY 32
> > static int abbrev;
> > static int ls_options;
> > static struct pathspec pathspec;
> > @@ -90,6 +91,14 @@ static int show_tree(const struct object_id *oid, struct strbuf *base,
> > else if (ls_options & LS_TREE_ONLY)
> > return 0;
> >
> > + if ((ls_options & LS_NAME_ONLY) && (ls_options & LS_OID_ONLY))
> > + die(_("cannot specify --oid-only and --name-only at the same time"));
>
> This seems reasonable to me. Letting them overwrite each other (i.e.,
> "last one wins") would also be fine, but we can always loosen to that
> behavior later if we choose.Oh, and whichever direction we go, it would probably make sense for --long to be handled in the same way. I.e.:
git ls-tree --long --oid-only
does not really make sense. Though we currently just ignore --long for:
git ls-tree --long --name-only
which is arguably a bug.
-Peff