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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jon Seymour <jon.seymour@xxxxxxxxx> 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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]