Re: [PATCH] Have a flag to stop the option parsing at the first argument.

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2208 bytes --]

Hi,

On Mon, 17 Dec 2007, Pierre Habouzit wrote:

> 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