Nelson Elhage [off-list ref] writes:
'-n' is the standard way to specify a dry run for other git commands,
so make 'git-push' accept it as well.
---
Sign-off?
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.
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?
On Sat, Sep 12, 2009 at 07:44:29PM -0700, Junio C Hamano wrote:
Sign-off?
Signed-off-by: Nelson Elhage <redacted>
(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.
On Sat, Sep 12, 2009 at 11:40:31PM -0400, Nelson Elhage wrote:
On Sat, Sep 12, 2009 at 07:44:29PM -0700, Junio C Hamano wrote:
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.
Oops, I missed 'commit' in your list, which I see (as of recently) has
that property. In that case, though, --dry-run was added after an
established -n option had been there for a long time; I think my
general argument still stands for commands where that is not the case.
- Nelson