Re: [PATCH/RFC] rev-parse: stop interpreting flags as options to rev-parse once --flags is specified
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 26, 2010, 07:11 UTC
- Message-ID
- <7v1v8hnflx.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <AANLkTim0oxhgtgqbrqP-jDL29jj0y=h6BLssEAFzags9@mail.gmail.com>
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).