git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Pierre Habouzit <madcoder@debian.org>, git@vger.kernel.org
Subject: Re: [PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
Date: Sun, 4 Nov 2007 13:48:36 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0711041343470.4362@racer.site> (raw)
In-Reply-To: <7v7ikytpz0.fsf@gitster.siamese.dyndns.org>

Hi,

On Sun, 4 Nov 2007, Junio C Hamano wrote:

> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > Also fix some space versus tabs issues.
> > ---
> >  git-checkout.sh |   99 +++++++++++++++++++++++++++----------------------------
> >  1 files changed, 49 insertions(+), 50 deletions(-)
> >
> > diff --git a/git-checkout.sh b/git-checkout.sh
> > index 8993920..5424745 100755
> > --- a/git-checkout.sh
> > +++ b/git-checkout.sh
> > @@ -1,6 +1,16 @@
> >  #!/bin/sh
> >  
> > -USAGE='[-q] [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
> > +PARSEOPT_OPTS=--keep-dashdash
> > +OPTIONS_SPEC="\
> > +git-branch [options] [<branch>] [<paths>...]
> > +--
> > +b=          create a new branch started at <branch>
> > +l           create the new branchs reflog
> > +track       tells if the new branch should track the remote branch
> > +f           proceed even if the index or working tree is not HEAD
> > +m           performa  three-way merge on local modifications if needed
> > +q,quiet     be quiet
> > +"
> 
> Ok, so this is how PARSEOPT_OPTS gets used.

I also read in the docs:

> It takes on the standard input the specification of the options to parse
> and understand, and echoes on the standard ouput a line suitable for 
> `sh(1)` `eval` to replace the arguments with normalized ones.

Why not go the full nine yards and output something which when eval'ed 
sets the variables correctly (taking the variable names from the option 
names; long name if available, otherwise short one)?  It can also set the 
command line arguments to what's left after option parsing, with a "set" 
call.

And to prevent funny games with "PARSEOPT_OPTS=blabla git xyz", why not 
provide a function in git-sh-setup which takes the string as argument, and 
is called _after_ sourcing git-sh-setup?

Ciao,
Dscho

  parent reply	other threads:[~2007-11-04 13:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-02 22:39 let's retry this based on git-rev-parse --parseopt Pierre Habouzit
2007-11-02 22:39 ` [PATCH 1/5] Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts Pierre Habouzit
2007-11-02 22:39   ` [PATCH 2/5] Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt Pierre Habouzit
2007-11-02 22:39     ` [PATCH 3/5] Migrate git-clean.sh to use " Pierre Habouzit
2007-11-02 22:39       ` [PATCH 4/5] Migrate git-clone " Pierre Habouzit
2007-11-02 22:39         ` [PATCH 5/5] Migrate git-am.sh " Pierre Habouzit
2007-11-03  9:55           ` Alex Riesen
2007-11-03 11:54             ` Pierre Habouzit
2007-11-03 12:05               ` Pierre Habouzit
2007-11-03 17:50         ` [PATCH 5/5 FIX SPACING] " Pierre Habouzit
2007-11-03 17:50           ` [PATCH 6/5] Migrate git-merge.sh " Pierre Habouzit
2007-11-03 17:50             ` [PATCH 8/5] Migrate git-instaweb.sh " Pierre Habouzit
2007-11-03 17:50               ` [PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash Pierre Habouzit
2007-11-03 17:50                 ` [PATCH 10/5] Migrate git-quiltimport.sh to use git-rev-parse --parseopt Pierre Habouzit
2007-11-03 18:35                   ` [PATCH 11/5] Migrate git-repack.sh " Pierre Habouzit
2007-11-04  7:44                 ` [PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash Junio C Hamano
2007-11-04  9:03                   ` Pierre Habouzit
2007-11-04 13:48                   ` Johannes Schindelin [this message]
2007-11-04 14:18                     ` Pierre Habouzit
2007-11-04  7:43     ` [PATCH 2/5] Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt Junio C Hamano
2007-11-04  9:11       ` [UPDATED PATCH 3/5] " Pierre Habouzit
2007-11-04  9:11         ` [UPDATED PATCH 5/5] Migrate git-clone to use " Pierre Habouzit
2007-11-04  9:11           ` [UPDATED PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash Pierre Habouzit
2007-11-04  9:14       ` [PATCH 2/5] Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt Pierre Habouzit
2007-11-04  9:15         ` Pierre Habouzit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0711041343470.4362@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=madcoder@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).