On 12/21/2012 06:12 PM, Junio C Hamano wrote:
> "diff" is always about two endpoints, not the path that connects
> these two endpoints (aka "range"), and when you want to "diff"
> between two commits, you say "diff A B".  "A..B" happens to be
> accepted as such only by accident (e.g. the old command line parser
> did not have a reliable way to tell "^A B" and "A..B" apart), not by
> design.
>     side note: incidentally, now we have rev_cmdline_info support,
>     we could start deprecating "diff A..B" syntax.

I often find myself using "git diff A..B" syntax when using the command
line history because the previous command used "A..B"; e.g.,

    git log A..B
    git diff A..B

It's quick to recall the previous command, edit "log" -> "diff", and
press enter; having to remove the dots would require a few extra keypresses.

> Actually, in many places where the command line parser knows it
> wants a single point, and never a range, we should be able to apply
> the "A...B as a notation to specify a single point" rule.  
> Of course you could come up with a symbol other than "..." for that
> purpose, and migrate the current "git checkout A...B" special case
> to use that other symbol, but that would be more work and also you
> would need to retrain existing users.

OTOH making A...B sometimes mean a range and sometimes a merge-base
(depending on context) adds a confusing non-uniformity, and also has the
disadvantage of making merge-base shorthand unavailable in contexts that
allow a range.

OTOOH git already has so many notations that can be used on the command
line; inventing yet another one would make it that much more overwhelming.


Michael Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to