From: Nelson Elhage <nelhage@MIT.EDU>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-push: Accept -n as a synonym for --dry-run.
Date: Sat, 12 Sep 2009 23:40:31 -0400 [thread overview]
Message-ID: <20090913034031.GO4275@mit.edu> (raw)
In-Reply-To: <7vfxar5zsi.fsf@alter.siamese.dyndns.org>
On Sat, Sep 12, 2009 at 07:44:29PM -0700, Junio C Hamano wrote:
> Sign-off?
Signed-off-by: Nelson Elhage <nelhage@mit.edu>
(I can resend the entire patch, but I'll resend with a new commit
message if appropriate after any discussion plays itself out).
>
> Indeed -n is used in many places for --dry-run, but it is not _the_
> standard way.
>
> commit, push (as you identified), reflog, and send-email have --dry-run
> but -n is not a synonym for it. Some of them even use -n as a shorthand
> for a more often used option than --dry-run.
Can you point to an example of a git command supporting --dry-run, and
using -n for something else? I personally would find that confusing,
since -n is a common alias for dry-run both inside and outside of git
(c.f. make, rsync, libtool). I guess patch(1) has that property, but
none of your examples from git use -n to mean something else.
In fact, reflog already supports '-n' to mean dry-run, it's just not
documented. I'll send along a documentation patch to fix that.
I got the claim that -n was "standard" from parse-options.h, which
defines OPT__DRY_RUN, which defines both -n and --dry-run switches at
the same time. Given the number of commands that treat them as
synonymous, I think it would be a win for UI consistency to make them
synonymous everywhere.
>
> So the justification should be more like "push does not any other option
> that deserves a short-and-sweet -n better, it will not have any such
> option in the future, and --dry-run is very often used that it deserves to
> use -n as its short-hand."
>
> I tend to agree with the first two points, but I am not sure about the
> third point. Do people dry-push that often?
I personally use --dry-run almost every time I push, which is what
inspired this patch. Especially now that the push.default can change
the behavior of push from repo to repo, I want to be sure I know what
I'm about to push. The recent 'git push --confirm' thread suggests I
am not the only person with this concern.
next prev parent reply other threads:[~2009-09-13 3:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-13 0:05 [PATCH] git-push: Accept -n as a synonym for --dry-run Nelson Elhage
2009-09-13 2:44 ` Junio C Hamano
2009-09-13 3:40 ` Nelson Elhage [this message]
2009-09-13 3:54 ` Nelson Elhage
2009-09-13 5:23 ` Junio C Hamano
2009-09-13 6:10 ` Junio C Hamano
2009-09-13 17:07 ` Nelson Elhage
2009-09-13 5:18 ` Junio C Hamano
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=20090913034031.GO4275@mit.edu \
--to=nelhage@mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).