Jeff King [off-list ref] writes:
On Fri, Feb 17, 2017 at 11:10:08PM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
The most gentle first step would be to try to turn the existing config
options where you can override cli-options into some declarative thing
from the current ad-hoc code we have for each one.
That would be no change in behavior, but would make it easier to
migrate more things in the future.
Yeah, I'd agree with that. It does not change anything for the users,
but it makes the implementation less annoying.
Yup, as long as that declarative thing (presumably it would hook
into parse-options that is already sort of declarative) allows some
command line options not overridable with configuration, I think it
would be OK.
I do not think anybody wants to see "reset --hard" and turn it into
"[reset] hard = yes" configuration, and we should not even allow for
that.
I think the conversation has drifted away from what I am asking / hoping for.
I apologize but I do not feel in the position of submitting patches
yet. I'll first need to read some code first before that.
I'm coming from the angle where currently I can alias just the command
(ex: l for log) not considering the 'command with options'.
[alias]
l = log
Currently, the order is as follows:
If built-in git command then it wins.
If custom git command (script as git-l) then it wins.
If alias for git command then it wins.
Else throw as unknown command.
In short, built-in git command > custom git command > git alias.
So I think, the same could also be used for options.
Say I want an alias for option --name-status as -s, so I can type:
$ git log -s
But there is already a -s option and that wins so the built-in option
alias wins.
However, I think I should be able alias it as --ns.
$ git log --ns
Thanks,
hippy
On Fri, Feb 17, 2017 at 02:34:15PM -0800, hIpPy wrote:
I think the conversation has drifted away from what I am asking / hoping for.
Yeah, the usual answer to "can we have custom options" is "use a custom
alias". But I agree they are not quite the same thing.
Say I want an alias for option --name-status as -s, so I can type:
$ git log -s
But there is already a -s option and that wins so the built-in option
alias wins.
However, I think I should be able alias it as --ns.
$ git log --ns
To be honest, I am not that enthused about the idea, but I don't have an
real objection beyond "meh, that looks like an unnecessary
complication".
If anybody wants to pursue it, the simplest way would probably be to
teach parse-options to take a callback for an unknown option, which
could then do a config lookup to transmute the argument into another
option-name.
Though many of the options (notably the revision-walker and diff ones)
are not handled by parse-options. So that might present a challenge.
-Peff