list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Matthieu Moy <>
To: Siddharth Kannan <>
Cc: Junio C Hamano <>,,,,,
Subject: Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"
Date: Wed, 08 Feb 2017 15:40:28 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20170207191450.GA5569@ubuntu-512mb-blr1-01.localdomain> (Siddharth Kannan's message of "Tue, 7 Feb 2017 19:14:50 +0000")

Siddharth Kannan <> writes:

> Making a change in sha1_name.c will touch a lot of commands
> (setup_revisions is called from everywhere in the codebase), so, I am
> still trying to figure out how to do this such that the rest of the
> codepath remains unchanged.

Changing sha1_name.c is the way to go *if* we want all commands to
support this. Just like other ways to name a revision...

> I hope that you do not mind this side-effect, but rather, you intended
> for this to happen, right? More commands will start supporting this
> shorthand, suddenly.  (such as format-patch, whatchanged, diff to name
> a very few).

... but: the initial implementation of this '-' shorthand was
special-casing a single command (IIRC, "git checkout") for which the
shorthand was useful.

In a previous discussion, I made an analogy with "cd -" (which is the
source of inspiration of this shorthand AFAIK): "-" did not magically
become "the last visited directory" for all Unix commands, just for
"cd". And in this case, I'm happy with it. For example, I never need
"mkdir -", and I'm happy I can't "rm -fr -" by mistake.

So, it's debatable whether it's a good thing to have all commands
support "-". For example, forcing users to explicitly type "git branch
-d @{1}" and not providing them with a shortcut might be a good thing.

I don't have strong opinion on this: I tend to favor consistency and
supporting "-" everywhere goes in this direction, but I think the
downsides should be considered too. A large part of the exercice here is
to write a good commit message!

Another issue with this is: - is also a common way to say "use stdin
instead of a file", so before enabling - for "previous branch", we need
to make sure it does not introduce any ambiguity. Git does not seem to
use "- for stdin" much (most commands able to read from stdin have an
explicit --stdin option for that), a quick grep in the docs shows only
"git blame --contents -" which is OK because a revision wouldn't make
sense here anyway.

Matthieu Moy

  reply	other threads:[~2017-02-08 15:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-05 12:57 Siddharth Kannan
2017-02-05 14:55 ` Pranit Bauva
2017-02-06  0:15 ` Junio C Hamano
2017-02-06  2:27   ` Siddharth Kannan
2017-02-06 18:10   ` Siddharth Kannan
2017-02-06 23:09     ` Junio C Hamano
2017-02-07 19:14       ` Siddharth Kannan
2017-02-08 14:40         ` Matthieu Moy [this message]
2017-02-08 17:23           ` Siddharth Kannan
2017-02-09 12:25             ` Matthieu Moy
2017-02-09 18:21               ` Siddharth Kannan

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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 read-only IMAP folder(s) and NNTP newsgroup(s).