From: Junio C Hamano <hidden> Date: 2016-06-15 22:55:34
Martin von Zweigbergk [off-list ref] writes:
I keep forgetting what "git diff A..B" does.
"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.
The special case "git checkout master...branch" is not about
specifying a range. The command knows it wants a single point (not
two endpoints, nor a range), and A...B as a notation to specify a
single point is $(merge-base A B).
I would have much preferred if
it was possible to make the revision parser generally interpret e.g.
"A.^.B" as "the merge base of A and B" (failing if not exactly one).
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.
From: Michael Haggerty <hidden> Date: 2016-06-15 22:55:34
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
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
From: Martin von Zweigbergk <hidden> Date: 2016-06-15 22:55:34
On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty [off-list ref] wrote:
On 12/21/2012 06:12 PM, Junio C Hamano wrote:
quoted
"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.
Off topic: I also find it hard to wrap my head around what diffing
against a negative revision would mean. Looking at the result of
running it, it seems to be the same as diffing against a positive one.
quoted
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
The problem with this, to me, if it wasn't clear, is that "git log
A..B" shows you is new _since B branched off from A_, while "git diff
A..B" shows you what has changed _between A and B_.
quoted
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.
And making it unavailable in contexts where the command was not
specifically implemented to support it. I'm sure there are many
scripts out there that use "git ... $(git merge-base A B) ..." that
could be simplified if rev-parse could resolve a merge base.
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.
From: Junio C Hamano <hidden> Date: 2016-06-15 22:55:34
Off topic: I also find it hard to wrap my head around what diffing
against a negative revision would mean. Looking at the result of
running it, it seems to be the same as diffing against a positive one.
That is not an off-topic at all, but is the crux of "diff A..B" being
a hysterical raisins.
It is parsed as and converted to "diff ^A B" by the revision command
line parser in
setup_revisions(), and the caller *guesses* what the command line
originally said by
inspecting that there are two revs in rev.pending[] array, the first
one is negative and
the second one is positive, to infer that the user typed "diff A..B"
and then finally
decides to compare A and B.
This was done before we introduced rev.cmdline_info to record what was
given from
the command line to result in the set of commits in rev.pending array.
If we were
writing "git diff" UI from scratch today, we wouldn't be looking at
rev.pending but
would be looking at rev.cmdline_info and we can differenciate between
"A B", "^A B",
and "A..B" (and reject the latter two as nonsense).
From: Michael Haggerty <hidden> Date: 2016-06-15 22:55:34
On 12/21/2012 10:31 PM, Martin von Zweigbergk wrote:
On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty [off-list ref] wrote:
quoted
On 12/21/2012 06:12 PM, Junio C Hamano wrote:
quoted
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
The problem with this, to me, if it wasn't clear, is that "git log
A..B" shows you is new _since B branched off from A_, while "git diff
A..B" shows you what has changed _between A and B_.
You are quite right, of course, though in many useful cases they are the
same. But I guess I should just buck myself up for the new orthodoxy :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/