Re: [PATCH/RFC] rev-parse: stop interpreting flags as options to rev-parse once --flags is specified

From: Jon Seymour <jon.seymour@gmail.com>
Date: Sep 26, 2010, 14:39 UTC
Message-ID: <AANLkTinQU3aoyBtD9-mSm_Oq5xiqNxmfJ-CncFgN1G07@mail.gmail.com>
In-Reply-To: <7v1v8hnflx.fsf@alter.siamese.dyndns.org>

On Sun, Sep 26, 2010 at 5:11 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 23 quoted lines

> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> Mmmm...almost certainly not going to regress anything, since there
>> does not seem to be a test or script that uses --flags. Ahem.
>
> I've already explained the historical background in a separate message; I
> realize that my message was missing the important part: conclusion.
>
> If there weren't rev-parse before and we were about to invent the command,
> I would agree that --flags should suppress output of HEAD.  Also I doubt
> anybody relies on --flags for the purpose of removing non-revision
> arguments.  So in that sense, your change would not hurt people.
>
> But I do not think encouraging the use of rev-parse to pick "flags" is a
> good idea in the longer term anyway, so I do not care too much about this
> issue.  Unless you will teach "rev-parse --flags" about all the options
> all other git command take (e.g. it should know --ignore-submodule takes
> an optional option argument and be able to parse "--ignore-submodule all"
> out), which is fundamentally impossible (e.g. for some commands "-n" does
> not take argument, for some other "-n" takes an integer argument, and the
> rev-parse command fundamentally cannot decide if it should report what
> follows "-n" as part of its "--flags" output).
>

Ok, so I have withdrawn the patch that makes --flags imply --no-revs.

v7 has 3 commits. The first commit documents existing behaviour more accurately. The second commit adds a test suite for existing behaviour.

I am offering the 3rd commit for discussion since your comments to date have not directly addressed this commit. To recap, this commit causes rev-parse to stop interpreting options once --flags is interpreted.

For example, this would allow:

$ git rev-parse --flags --all --all $

whereas currently:

$ git rev-parse --flags --all
 .. list of revisions ..
$

As it stands, --flags really can't be used for any useful purpose. It can't be used to output arbitrary flag or rev-like arguments compatible with rev-list because it eats --all for itself. it can't be used with any option that it also recognises (such as -q).

This being the case, one has to wonder whether we shouldn't just deprecate --flags so that people don't waste time trying to use it.

jon.