* Confusion about diffing branches @ 2007-08-26 23:35 Shawn Bohrer 2007-08-27 0:18 ` Junio C Hamano 0 siblings, 1 reply; 14+ messages in thread From: Shawn Bohrer @ 2007-08-26 23:35 UTC (permalink / raw) To: git 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 If I want to see a diff of all of the changes between the two branches I can say: git diff master topic Which shows me the combined diff of commits A, B and E. That is exactly what I would expect however, I would expect that equivalently I could say: git diff master...topic to see all commits reachable from topic and master but not both. However, this doesn't do what I expect but instead only shows me the combined diff of A and B. Likewise: git diff topic...master Shows me the diff of E. Am I crazy or isn't this supposed to be the behavior of the topic..master notation? Strangely enough running either git diff master..topic git diff topic..master both show me the diff of A, B and E, which is what I would expect from the master...topic notation. Am I the only one who thinks this is backwards? The same experiment using git log shows me what I would expect so somehow I think I'm missing something. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-26 23:35 Confusion about diffing branches Shawn Bohrer @ 2007-08-27 0:18 ` Junio C Hamano 2007-08-27 1:40 ` Shawn Bohrer 0 siblings, 1 reply; 14+ messages in thread From: Junio C Hamano @ 2007-08-27 0:18 UTC (permalink / raw) To: Shawn Bohrer; +Cc: git Shawn Bohrer <shawn.bohrer@gmail.com> 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 0:18 ` Junio C Hamano @ 2007-08-27 1:40 ` Shawn Bohrer 2007-08-27 6:25 ` Mike Hommey ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Shawn Bohrer @ 2007-08-27 1:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 1:40 ` Shawn Bohrer @ 2007-08-27 6:25 ` Mike Hommey 2007-08-27 7:07 ` Junio C Hamano 2007-08-27 22:20 ` Jakub Narebski 2 siblings, 0 replies; 14+ messages in thread From: Mike Hommey @ 2007-08-27 6:25 UTC (permalink / raw) To: Shawn Bohrer; +Cc: Junio C Hamano, git On Sun, Aug 26, 2007 at 08:40:56PM -0500, Shawn Bohrer <shawn.bohrer@gmail.com> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 1:40 ` Shawn Bohrer 2007-08-27 6:25 ` Mike Hommey @ 2007-08-27 7:07 ` Junio C Hamano 2007-08-27 7:50 ` Mike Hommey 2007-08-27 22:20 ` Jakub Narebski 2 siblings, 1 reply; 14+ messages in thread From: Junio C Hamano @ 2007-08-27 7:07 UTC (permalink / raw) To: Shawn Bohrer; +Cc: git Shawn Bohrer <shawn.bohrer@gmail.com> 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 7:07 ` Junio C Hamano @ 2007-08-27 7:50 ` Mike Hommey 2007-08-27 13:21 ` Francis Moreau 0 siblings, 1 reply; 14+ messages in thread From: Mike Hommey @ 2007-08-27 7:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: Shawn Bohrer, git On Mon, Aug 27, 2007 at 12:07:39AM -0700, Junio C Hamano <gitster@pobox.com> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 7:50 ` Mike Hommey @ 2007-08-27 13:21 ` Francis Moreau 2007-08-27 13:33 ` Mike Hommey 2007-08-27 17:05 ` Theodore Tso 0 siblings, 2 replies; 14+ messages in thread From: Francis Moreau @ 2007-08-27 13:21 UTC (permalink / raw) To: Mike Hommey; +Cc: Junio C Hamano, Shawn Bohrer, git Hi ! On 8/27/07, Mike Hommey <mh@glandium.org> wrote: > On Mon, Aug 27, 2007 at 12:07:39AM -0700, Junio C Hamano <gitster@pobox.com> 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. > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 13:21 ` Francis Moreau @ 2007-08-27 13:33 ` Mike Hommey 2007-08-27 17:06 ` Junio C Hamano 2007-08-27 17:05 ` Theodore Tso 1 sibling, 1 reply; 14+ messages in thread From: Mike Hommey @ 2007-08-27 13:33 UTC (permalink / raw) To: Francis Moreau; +Cc: Junio C Hamano, Shawn Bohrer, git On Mon, Aug 27, 2007 at 03:21:32PM +0200, Francis Moreau <francis.moro@gmail.com> wrote: > Hi ! > > On 8/27/07, Mike Hommey <mh@glandium.org> wrote: > > On Mon, Aug 27, 2007 at 12:07:39AM -0700, Junio C Hamano <gitster@pobox.com> 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. > > > > 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... Actually, they may have a good point, cf. the thread you point. But it is annoying that it is not documented. Mike ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 13:33 ` Mike Hommey @ 2007-08-27 17:06 ` Junio C Hamano 2007-08-27 17:24 ` Mike Hommey 0 siblings, 1 reply; 14+ messages in thread From: Junio C Hamano @ 2007-08-27 17:06 UTC (permalink / raw) To: Mike Hommey; +Cc: Francis Moreau, Shawn Bohrer, git Mike Hommey <mh@glandium.org> writes: > On Mon, Aug 27, 2007 at 03:21:32PM +0200, Francis Moreau <francis.moro@gmail.com> wrote: >> >> 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... > > Actually, they may have a good point, cf. the thread you point. > But it is annoying that it is not documented. Would something like this reduce the annoyance factor? --- Documentation/git-diff.txt | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index b36e705..04b62d9 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -42,14 +42,28 @@ tree and the index file, or the index file and the working tree. branch name to compare with the tip of a different branch. -'git-diff' [--options] <commit> <commit> [--] [<path>...]:: +'git-diff' [--options] <commit1> <commit2> [--] [<path>...]:: This form is to view the changes between two <commit>, for example, tips of two branches. +'git-diff' [--options] <commit1>..<commit2> [--] [<path>...]:: + + This is identical to the previous one, just to make the + specification of two commits look similar to a commit + range notation. + +'git-diff' [--options] <commit1>...<commit2> [--] [<path>...]:: + + This compares the merge base of two commits and the + second commit. Useful to view what happened in the + history that leads to the second commit since that + history forked from the history that leads to the first + commit. + Just in case if you are doing something exotic, it should be -noted that all of the <commit> in the above description can be -any <tree-ish>. +noted that all of the <commit> in the above description, +except for the last two variants, can be any <tree-ish>. For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 17:06 ` Junio C Hamano @ 2007-08-27 17:24 ` Mike Hommey 0 siblings, 0 replies; 14+ messages in thread From: Mike Hommey @ 2007-08-27 17:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: Francis Moreau, Shawn Bohrer, git [-- Attachment #1: Type: text/plain, Size: 754 bytes --] On Mon, Aug 27, 2007 at 10:06:21AM -0700, Junio C Hamano <gitster@pobox.com> wrote: > Mike Hommey <mh@glandium.org> writes: > > > On Mon, Aug 27, 2007 at 03:21:32PM +0200, Francis Moreau <francis.moro@gmail.com> wrote: > >> > >> 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... > > > > Actually, they may have a good point, cf. the thread you point. > > But it is annoying that it is not documented. > > Would something like this reduce the annoyance factor? I was actually working on the attached diff, though I'm not really convinced by my wording. Mike [-- Attachment #2: diff --] [-- Type: text/plain, Size: 2192 bytes --] Documentation/git-diff.txt | 32 ++++++++++++++++++++++++++++++-- 1 files changed, 30 insertions(+), 2 deletions(-) diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index b36e705..082ac0b 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -43,9 +43,22 @@ tree and the index file, or the index file and the working tree. branch. 'git-diff' [--options] <commit> <commit> [--] [<path>...]:: +'git-diff' [--options] <commit>..<commit> [--] [<path>...]:: - This form is to view the changes between two <commit>, - for example, tips of two branches. + These forms are to view the changes between two <commit>, + for example, tips of two branches. In the second form, + omitting any one of both <commit> will have the same effect + as using HEAD. + +'git-diff' [--options] <commit>...<commit> [--] [<path>...]:: + + This form is to view the changes on the branch containing + and up to the second <commit>, starting at a common ancestor + of both <commit>. + "git-diff A...B" is equivalent to + "git-diff `git-merge-base A B` B" + You can omit any one of both <commit>, which has the same + effect as using HEAD. Just in case if you are doing something exotic, it should be noted that all of the <commit> in the above description can be @@ -54,6 +67,9 @@ any <tree-ish>. For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. +Be careful that despite looking like so, both "<commit>..<commit>" +and "<commit>...<commit>" forms are NOT ranges as described in +the "SPECIFYING RANGES" section in gitlink:git-rev-parse[1]. OPTIONS ------- @@ -97,6 +113,18 @@ the tip of the current branch, but limit the comparison to the file "test". <3> Compare the version before the last commit and the last commit. +Comparing branches:: ++ +------------ +$ git diff topic master <1> +$ git diff topic..master <2> +$ git diff topic...master <2> +------------ ++ +<1> Changes between the tips of the topic and the master branches. +<2> Same as <1> +<3> Changes that occured on the master branch since when the topic +branch was started off it. Limiting the diff output:: + ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 13:21 ` Francis Moreau 2007-08-27 13:33 ` Mike Hommey @ 2007-08-27 17:05 ` Theodore Tso 2007-08-27 17:20 ` Junio C Hamano 1 sibling, 1 reply; 14+ messages in thread From: Theodore Tso @ 2007-08-27 17:05 UTC (permalink / raw) To: Francis Moreau; +Cc: Mike Hommey, Junio C Hamano, Shawn Bohrer, git On Mon, Aug 27, 2007 at 03:21:32PM +0200, Francis Moreau wrote: > This "inconsistency" had already been raised before. Please refer to: > http://www.gelato.unsw.edu.au/archives/git/0612/35354.html 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 17:05 ` Theodore Tso @ 2007-08-27 17:20 ` Junio C Hamano 2007-08-27 20:29 ` Theodore Tso 0 siblings, 1 reply; 14+ messages in thread From: Junio C Hamano @ 2007-08-27 17:20 UTC (permalink / raw) To: Theodore Tso; +Cc: Francis Moreau, Mike Hommey, Shawn Bohrer, git Theodore Tso <tytso@mit.edu> writes: > 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. Heh, I really hate when people say this. If you wanted to, you could: $ git format-patch a a The original syntax $ git format-patch upstream may have been a mistake and maybe $ git format-patch ^upstream or even $ git format-patch --since upstream might have been better. It is (1) too late to change now, and (2) for too small or perhaps negative a gain. The reason why I say (2) is because _I_ think it is far more common and frequent to want to get "patches the other guy does not have" than "everything since nothingness up to this point". Oops. I think I have a solution. $ git format-patch a a does not do _ROOT_ commit. So you have to say $ git format-patch --root a a for the above example to work. Why not tweak the option parser so that: $ git format-patch --root a to do what you want? Without --root and with a single positive commit, it can keep doing the traditional "what I did since I forked from that guy's history". Hmm... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 17:20 ` Junio C Hamano @ 2007-08-27 20:29 ` Theodore Tso 0 siblings, 0 replies; 14+ messages in thread From: Theodore Tso @ 2007-08-27 20:29 UTC (permalink / raw) To: Junio C Hamano; +Cc: Francis Moreau, Mike Hommey, Shawn Bohrer, git On Mon, Aug 27, 2007 at 10:20:42AM -0700, Junio C Hamano wrote: > If you wanted to, you could: > > $ git format-patch a a Umm.... dare I ask why this works, or how someone would be expected to know this? Or is the answer, "Meditate deeply on builtin-log.c, grasshopper"? :-) > might have been better. It is (1) too late to change now, and > (2) for too small or perhaps negative a gain. > > The reason why I say (2) is because _I_ think it is far more > common and frequent to want to get "patches the other guy does > not have" than "everything since nothingness up to this point". I agree, "patches the other guy does not have" is usually the more common desired result. The problem is that it breaks the regularity of git's command line parsing, which is particularly painful given that users are told to read the man page for git-rev-list and git-rev-parse in order to understand all of the many, many options that might be valid. The fact that the man pages expect the user to do this kinda implies that there is a regularity and orthogonality to git's command structure --- which there is, mostly --- which makes the git-format-patch "hack" that much more surprising. So it's just one of those things which is surprising to someone who hasn't been fingers deep in the guts of the git implementation for years and years. I think it took me a good hour or two of searching before I was able to even figure out how the special case for git-format-patch was getting implemented; it certainly wasn't well documented in the code last year when I went searching to figure out what the !@#@? was going on. > Oops. I think I have a solution. > > $ git format-patch a a > > does not do _ROOT_ commit. So you have to say > > $ git format-patch --root a a Wow, I had no idea that --root would even be accepted by git-format-patch. It's not mentioned in the documentation, and a grep of Documentation/*.txt shows that --root is only mentioned in the man pages for git-blame, git-fsck, and git-diff-tree. I assume it's the latter which is getting used here, but there isn't even a mention in the git-format-patch man page that options from git-diff-tree might be applicable. I presume this is another, "meditate deeply on builtin-log.c and revision.c, and understand that they implement many diverse builtin commands, grasshopper" situation.... > for the above example to work. Why not tweak the option parser > so that: > > $ git format-patch --root a > > to do what you want? Without --root and with a single positive > commit, it can keep doing the traditional "what I did since I > forked from that guy's history". That seems to make a lot of sense; given the fact that the current behaivor does make sense and is convenient, the big complaints were always (1) not documenting clearly that this was an exception which might be surprising (i.e., hanging a latern[1] on it), and (2) that there wasn't a way to do the alternate expected behavior. --root handles the second, and an explanation in the man page saying that yes, this is a little non-standard wrt to git-rev-list, but it's convenient, and let the user know that he should just give us a pass on it the non-orthoganlity. - Ted [1] Daniel: The mountain... blows up? Martin: No possible hope for survival! Cool huh? I just wrote it based on what's going on with the gate. I love it when art imitates life. Mitchell: Hang on. We're alive in the next scene. Martin: Oh, I just haven't fixed that part yet. I'm thinking I can back-sell it and say you were beamed out at the last second. Daniel: "Beamed out?" Martin: Sure, why not? Teal'c: Is that not too convenient? Martin: Not if you hang a lantern on it. Daniel: What's that? Martin: It's a writer's term. Another character points out how convenient it is. Doctor Levant can say, "Wow, that was great timing." That way, the audience knows I intended for it to be convenient, and we move on. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Confusion about diffing branches 2007-08-27 1:40 ` Shawn Bohrer 2007-08-27 6:25 ` Mike Hommey 2007-08-27 7:07 ` Junio C Hamano @ 2007-08-27 22:20 ` Jakub Narebski 2 siblings, 0 replies; 14+ messages in thread From: Jakub Narebski @ 2007-08-27 22:20 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2007-08-27 22:21 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-08-26 23:35 Confusion about diffing branches Shawn Bohrer 2007-08-27 0:18 ` Junio C Hamano 2007-08-27 1:40 ` Shawn Bohrer 2007-08-27 6:25 ` Mike Hommey 2007-08-27 7:07 ` Junio C Hamano 2007-08-27 7:50 ` Mike Hommey 2007-08-27 13:21 ` Francis Moreau 2007-08-27 13:33 ` Mike Hommey 2007-08-27 17:06 ` Junio C Hamano 2007-08-27 17:24 ` Mike Hommey 2007-08-27 17:05 ` Theodore Tso 2007-08-27 17:20 ` Junio C Hamano 2007-08-27 20:29 ` Theodore Tso 2007-08-27 22:20 ` Jakub Narebski
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 NNTP newsgroup(s).