Re: [PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 23, 2008 at 01:17:52AM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> 
> > diff --git a/builtin-checkout.c b/builtin-checkout.c
> > index fbd5105..1490e8e 100644
> > --- a/builtin-checkout.c
> > +++ b/builtin-checkout.c
> > @@ -438,9 +438,14 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> >  
> >  	opts.track = git_branch_track;
> >  
> > -	argc = parse_options(argc, argv, options, checkout_usage, 0);
> > -	if (argc) {
> > +	argc = parse_options(argc, argv, options, checkout_usage,
> > +			     PARSE_OPT_KEEP_DASHDASH);
> > +
> > +	if (argc && strcmp(argv[0], "--")) {
> >  		arg = argv[0];
> > +
> > +		if (argc == 1 || strcmp(argv[1], "--"))
> > +			verify_non_filename(NULL, arg);
> 
> Why "argc == 1"?  Should "git checkout <path>" really fail?  That would be 
> a change in behavior that _would_ hit me.

  No I was mistaken about what verify_non_filename did, actually I
should not code when I'm so obviously tired, and I wanted
verify_non_filename to do what I meant instead of checking what it does
;P

  I believe my resent patch is better.

> However, you may want to verify_non_filename() when argc == 1 _and_ 
> get_sha1() succeeded.  Because then, <path> is ambiguous.

  Yes and the reverse when we have sucessfully parsed something that
looks like a path as a path. Anyways, someone should carefully proofread
my resent patch, it's likely that errors slipped through given my sleep
deprivation atm.

Attachment: pgpJytlZuzMm9.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux