El 17/12/2007, a las 9:48, Junio C Hamano escribió:
Wincent Colaiuta <win@xxxxxxxxxxx> writes:
Of course, the above plan will only work for builtins, not for
scripts. An additional step would be needed to enable scripts to
handle these options; perhaps teaching "git rev-parse" something...
As long as special options stay special and we make a rule not to
allow
any subcommand to assign its own meaning to them, the git wrapper can
lookahead and reorder, when seeing a command line:
git scripted-command --special
into
git --special scripted-command
And that approach would work well for built-ins as well, I would
imagine.
Yes, and it would be simpler to implement also. The only downside is
that without all the other proposed changes things like "git-dashed --
special" wouldn't work; only teaching the builtins to actually handle
the special options would work in that case. And in the interests of
consistency I think it's pretty important that "git subcommand --
special" and "git-subcommand --special" both work the same as the user
would (reasonably) expect them to...
There is one minor detail, though. There could be an option-parameter
that is literally --special. E.g.
git grep -e --no-paginate
should not be reordered to
git --no-paginate grep -e
Yes, that's definitely one that would need to be treated as a special
case.
Cheers,
Wincent
-
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
