Re: [PATCH] Have a flag to stop the option parsing at the first argument.
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Dec 17, 2007, 11:50 UTC
- Message-ID
- <Pine.LNX.4.64.0712171149540.9446@racer.site>
- In-Reply-To
- <20071217114703.GH7453@artemis.madism.org>
Hi,
On Mon, 17 Dec 2007, Pierre Habouzit wrote:
Show 48 quoted lines
> On Mon, Dec 17, 2007 at 11:10:00AM +0000, Wincent Colaiuta wrote:
> > El 17/12/2007, a las 10:50, Pierre Habouzit escribió:
> >
> > >Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> > >---
> > >> // ...
> > >> /* when in `git --opt1 --opt2 foo -a -b -c` mode: */
> > >> int cmd_pos = git_find_builtin_command_name(argc, argv);
> > >> int count = parse_options(cmd_pos, argv, git_generic_options,
> > >> "git [special-options] cmd [options]", 0);
> > >> if (count)
> > >> die("unknown git command: `%s`", argv[0]);
> > >> argv += cmd_pos;
> > >> argc -= cmd_pos;
> > >> /* here we simulate an argv of {"foo", "-a", "-b", "-c"} */
> > >
> > > Or even simpler, with the following specifically tailored patch you
> > > can directly write:
> > >
> > > argc = parse_options(argc, argv, git_generic_options,
> > > "git [generic-options] <command> [cmd-options]",
> > > PARSE_OPT_STOP_AT_ARG);
> > >
> > > and then {argc, argv} will exactly be the NULL-terminated array
> > > starting with the builtin command. Kind of nice :)
> >
> > Indeed, nice ideas. I think all this will lead to a nice UI improvement
> > post-1.5.4.
> >
> > About the only thing that I think would merit action *prior* to 1.5.4 is
> > marking the "-p" switch to git (synonym for --paginate) as deprecated,
> > see as it clashes with other commands' uses of that switch ("git log -p"
> > for example). Are there any other conflicting specials that a currently
> > parsed in git.c?
>
> You don't need to, and I'd see that as a regression. With my proposal,
> there isn't any kind of need that git commands do not clash with git
> ones. The parse-option mechanism will properly hide options that are
> masked this way, dscho wrote the patch for that.
>
> git -p log -p ...
>
> just makes sense to me. CVS or SVN e.g. (don't hit me !) have the same
> kind of "issues", and I never found that weird.
>
> In fact I see this the other way around: git status -p that is in fact
> the same as git -p status, is the conveniency, git -p status is the
> canonical form.I would even go further: "git status -p" looks utterly wrong to me.
Ciao, Dscho