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
next prev parent 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).