git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
	Nanako Shiraishi <nanako3@lavabit.com>,
	git@vger.kernel.org, Pierre Habouzit <madcoder@debian.org>
Subject: [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
Date: Sat, 12 Sep 2009 05:03:51 +0200	[thread overview]
Message-ID: <20090912030351.GC18684@vidovic> (raw)
In-Reply-To: <7v8wglw60x.fsf@alter.siamese.dyndns.org>

[ Thank you (again) for this very good explanation. ]

The 11/09/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> 
> > Ok. So, the fact that the usage of git-am doesn't tell about
> > --no-scissors is the expected behaviour?
> 
> You _could_ argue that we _could_ describe a long option "frotz" that
> lacks the '!' flag in OPTIONS_SPEC as "--[no-]frotz" in the output by
> changing the rev-parse --parseopt, if you really want to.
> 
> However, I think that is not done deliberately to avoid cluttering the
> output.  I Cc'ed the primary guilty party ;-) of the parse-options
> infrastructure.

Well, if it is expected to not have the "--[no-]frotz" in usage where
applicable I'll be fine with that (even if it may sounds a bit odd for a
sane user). Otherwise, I believe it could be a (small) improvement for
the UI.

> Currently, non-bool options are not marked with '!'.  Nobody sane would
> say "git am --no-directory foo", but "rev-parse --parseopt" acccepts such
> a nonsense input, and it is up to the calling script to catch it and barf.
> But "rev-parse --parseopt" will start saying "--[no-]directory=" with such
> a change, which is not good.
> 
> And --no-scissors is not that special.  We could add --no-signoff to say
> "I do not want to sign-off this one time" explicitly, and it is crazy if
> we had to add another line in OPTIONS_SPEC when we want to do so, when it
> is clear "signoff" option is a boolean.
> 
> As a long term direction, I'd rather not to see "no-" in OPTIONS_SPEC, but
> have that taken care of by "rev-parse --parseopt" to keep our sanity.  The
> only existing offender is "no-verify" in "rebase -i".  Let's solve it (if
> there is anything to solve, which I doubt) without adding new ones.

Now (with all this background in mind), I agree that the "no-" in
OPTIONS_SPEC looks ugly.

<If there were something to change>

As you say, we can't blindly rely on the "is a boolean" and "option name
begin with 'no-'" things altogether. Perhaps a new magic character
('-'?) beside the current flags of PARSEOPT could smartly do the trick?

</>

Pierre, opinion?

-- 
Nicolas Sebrecht

  reply	other threads:[~2009-09-12  3:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08  0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
2009-09-08  6:31 ` Nanako Shiraishi
2009-09-08  6:48   ` Junio C Hamano
2009-09-08 13:10 ` Jakub Narebski
2009-09-08 13:17 ` Sverre Rabbelier
2009-09-09 11:59 ` jk/1.7.0-status, was: " Jeff King
2009-09-10 16:18 ` Daniel Barkalow
2009-09-10 16:53   ` Johannes Schindelin
2009-09-10 17:55     ` Daniel Barkalow
2009-09-10 18:41     ` Junio C Hamano
2009-09-11  0:09 ` scissors definition and documentation Nicolas Sebrecht
2009-09-11  0:09 ` [PATCH 1/2] mailinfo: add '--scissors' to usage message Nicolas Sebrecht
2009-09-11  0:09   ` [PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors' Nicolas Sebrecht
2009-09-11  0:29     ` [PATCH v2] " Nicolas Sebrecht
2009-09-11  7:19       ` Junio C Hamano
2009-09-11 13:41         ` [PATCH v2] " Nicolas Sebrecht
2009-09-11 18:53           ` Junio C Hamano
2009-09-11 20:08             ` Nicolas Sebrecht
2009-09-11 21:00               ` Junio C Hamano
2009-09-12  3:03                 ` Nicolas Sebrecht [this message]
     [not found]         ` <682ef47420f36d8c53e42981370d377b621d7b86.1252698215.git.nicolas.s.dev@gmx.fr>
2009-09-11 19:50           ` [PATCH v3 2/2] " Nicolas Sebrecht
2009-09-12  0:33 ` What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
2009-09-12  4:38   ` Junio C Hamano
2009-09-12 11:46   ` Sverre Rabbelier

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=20090912030351.GC18684@vidovic \
    --to=nicolas.s.dev@gmx.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=madcoder@debian.org \
    --cc=nanako3@lavabit.com \
    /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).