From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:31
Shawn Bohrer [off-list ref] writes:
So I imagine I'm missing something, or perhaps I'm just looking at this
from the wrong perspective, but here is what I'm seeing. Lets say I
have something like:
A---B topic
/
C---D---E master
...
git diff master...topic
... shows me the
combined diff of A and B.
That is working as designed.
When you are working on topic it is often desired to see "what
have I done since I forked?" and "what have they done while I
was looking the other way?".
"git diff master topic" (which is the same as "git diff
master..topic" -- the two-dot form is just a syntax sugar to
avoid mistypes for people who are too used to type two dots as
reflex because that is how you express a revision range) shows
a squashed diff that is A+B-E, and often people found "-E" part
distracting and useless. Three-dot form was invented
specifically to address this problem. You do not have to (and
you do not _want_ to) use that form if you _want_ to see the -E
part of the diff.
On Sun, Aug 26, 2007 at 05:18:35PM -0700, Junio C Hamano wrote:
When you are working on topic it is often desired to see "what
have I done since I forked?" and "what have they done while I
was looking the other way?".
Absolutely, and from the user manual I gathered that this was what the
two-dot form was for. "git diff master..topic" show me the diff of
commits reachable from topic, but not from master.
The three-dot form seemed to address the other use case which is
probably the more usual case for git-diff which is show me the changes
reachable from master or topic but not both.
"git diff master topic" (which is the same as "git diff
master..topic" -- the two-dot form is just a syntax sugar to
avoid mistypes for people who are too used to type two dots as
reflex because that is how you express a revision range) shows
a squashed diff that is A+B-E, and often people found "-E" part
distracting and useless. Three-dot form was invented
specifically to address this problem. You do not have to (and
you do not _want_ to) use that form if you _want_ to see the -E
part of the diff.
So if I understand you correctly people in the git world are simply more
used to typing two dots (instead of three) so that is why the two dot
notation shows the more common use case (show me the difference between
the tip of the master branch and the tip of the topic branch).
I must admit that for me, a new git user, it would be much more
intuitive if all git commands used the same syntax for specifying
revisions. After all every other git command that I have used so far
uses the opposite syntax as git-diff. This includes git-log,
git-format-patch, gitk, git-rev-list, and git-rev-parse.
From: Mike Hommey <hidden> Date: 2016-06-15 22:43:31
On Sun, Aug 26, 2007 at 08:40:56PM -0500, Shawn Bohrer [off-list ref] wrote:
So if I understand you correctly people in the git world are simply more
used to typing two dots (instead of three) so that is why the two dot
notation shows the more common use case (show me the difference between
the tip of the master branch and the tip of the topic branch).
I must admit that for me, a new git user, it would be much more
intuitive if all git commands used the same syntax for specifying
revisions. After all every other git command that I have used so far
uses the opposite syntax as git-diff. This includes git-log,
git-format-patch, gitk, git-rev-list, and git-rev-parse.
Similar experience here. It is even more a problem for newcomers when
you consider it isn't documented in either git-rev-parse or git-diff
manual pages.
Mike
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:31
Shawn Bohrer [off-list ref] writes:
So if I understand you correctly people in the git world are simply more
used to typing two dots (instead of three) so that is why the two dot
notation shows the more common use case (show me the difference between
the tip of the master branch and the tip of the topic branch).
No, what I said was that two dot form is merely there to avoid
saying 'if you want to diff two trees, do not say "diff a..b"
but say "diff a b", dummy!'. Instead of giving such an error
message, we just say "oh, you want difference between a and b?
here it is".
As to which is common between "diff a..b" and "diff a...b", that
really depends. You seem to be hinting that you think a...b is
more useful but that is not always the case. Comparing two
arbitrary trees _is_ the base form of diff, and that is what
"diff a b" gives you. It does not require two trees to be
related in ancestry relationships in _any_ way. For example,
you can say "git diff v2.6.20 v2.6.21" or "git diff v2.6.20.4
v2.6.21.2".
On the other hand, when you are into topic branch development
workflow, "diff a...b" is often useful but that does not mean
people using topic branch development does not need "diff a b"
form. You can say either "diff a b" if you want straight diff
between two trees, or "diff a...b" if you want "what happened in
b, since it forked from the history leading to a"; if the
two-dot form confuses you, you do not have to use that synonym.
Both semantics of two-dot form and three-dot form are useful,
and choice between the two depends on what you want out of the
command. You just need to know which one you want.
From: Mike Hommey <hidden> Date: 2016-06-15 22:43:31
On Mon, Aug 27, 2007 at 12:07:39AM -0700, Junio C Hamano [off-list ref] wrote:
Both semantics of two-dot form and three-dot form are useful,
and choice between the two depends on what you want out of the
command. You just need to know which one you want.
The problem is not about usefulness of these 2 forms, but consistency
with the rest of the tools.
If I go git log a..b, I won't get the set of commits involved in
git diff a..b. In fact, git log a...b does. And git log a..b gives the
commits involved in git diff a...b. Confusing, isn't it ?
Moreover, this inconsistency isn't even documented in the manual pages.
Mike
From: Francis Moreau <hidden> Date: 2016-06-15 22:43:31
Hi !
On 8/27/07, Mike Hommey [off-list ref] wrote:
On Mon, Aug 27, 2007 at 12:07:39AM -0700, Junio C Hamano [off-list ref] wrote:
quoted
Both semantics of two-dot form and three-dot form are useful,
and choice between the two depends on what you want out of the
command. You just need to know which one you want.
The problem is not about usefulness of these 2 forms, but consistency
with the rest of the tools.
If I go git log a..b, I won't get the set of commits involved in
git diff a..b. In fact, git log a...b does. And git log a..b gives the
commits involved in git diff a...b. Confusing, isn't it ?
Moreover, this inconsistency isn't even documented in the manual pages.
This "inconsistency" had already been raised before. Please refer to:
http://www.gelato.unsw.edu.au/archives/git/0612/35354.html
I shared and still share your feeling about that but it seems that
Junio and Linus don't...
good luck ;)
--
Francis
From: Mike Hommey <hidden> Date: 2016-06-15 22:43:31
On Mon, Aug 27, 2007 at 03:21:32PM +0200, Francis Moreau [off-list ref] wrote:
Hi !
On 8/27/07, Mike Hommey [off-list ref] wrote:
quoted
On Mon, Aug 27, 2007 at 12:07:39AM -0700, Junio C Hamano [off-list ref] wrote:
quoted
Both semantics of two-dot form and three-dot form are useful,
and choice between the two depends on what you want out of the
command. You just need to know which one you want.
The problem is not about usefulness of these 2 forms, but consistency
with the rest of the tools.
If I go git log a..b, I won't get the set of commits involved in
git diff a..b. In fact, git log a...b does. And git log a..b gives the
commits involved in git diff a...b. Confusing, isn't it ?
Moreover, this inconsistency isn't even documented in the manual pages.
That's not a major inconsistency problem IMHO because git diff does
not take a set of commits, but rather two end points --- conceptually,
there's no way to make sense out of trying to feed an arbitrary set of
commitments to git-diff.
The bigger inconsistency is with git-format-patch, which *does* take a
set of commits, and where "git-format-patch a" does operates on a very
different set of commits than what what "git-rev-list a" returns. I
understand that for backwards compatibility "git-format-patch a" is
equivalent to "git-format-patch a..HEAD", but what it means is that
all other ways of specifying sets of commits work with
git-format-patch, *except* if you want to specify all commits from the
beginning of time to a particular head (i.e., "git-rev-list a") is
something that you simply can not possibly do using git-format-patch.
This was mentioned on a blog entry as one of those "really confusing
inconsistencies" in git.
- Ted
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:31
Shawn Bohrer wrote:
I must admit that for me, a new git user, it would be much more
intuitive if all git commands used the same syntax for specifying
revisions. After all every other git command that I have used so far
uses the opposite syntax as git-diff. This includes git-log,
git-format-patch, gitk, git-rev-list, and git-rev-parse.
git-rev-list, git-log, gitk accepts _range_ of commits. git-diff and
its variants accepts _endpoints_ to compare, with some syntactic sugar
to be able to copy arguments from "git log a..b" to "git diff a..b".
The arguments are just simply different type.
As to git-format-patch, there is matter of backward compatibilty
and ease of use (get last commit as a patch).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git