# [q] git-diff --reverse 7def2be1..7def2be1^ 25 messages from 2008-06-20 to 2008-07-07. Participants: Ingo Molnar, Junio C Hamano, Jakub Narebski, Matthieu Moy, Mikael Magnusson, Andreas Ericsson, Nicolas Pitre, Dmitry Potapov. Thread: https://gitlist.dev/t/14055 ## Ingo Molnar, 2008-06-20 08:20 Subject: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080620082034.GA24913@elte.hu> URL: https://gitlist.dev/e/20080620082034.GA24913%40elte.hu ``` A couple of stupid Git questions (using git-1.5.4.3-2.fc8). Sometimes i want to see the reverse diff of a particular commit. If i want to see the normal diff i do: git-log -1 -p 7def2be1 But generating the reverse diff does not work: git-log --reverse -1 -p 7def2be1 Because the '--reverse' here is the ordering of the revlist, not the direction of the patch itself. And that's OK, albeit slightly unintuitive. So instead i do: git-diff --reverse 7def2be1..7def2be1^ I've got two observations / potential suggestions: 1) the SHA1 is duplicated above, is there a way to avoid it? Initially i tried the obvious extension: git-diff --reverse 7def2be1..^ But Git didnt recognize that as a valid commit range. 2) is there a way to pass something like --reversediff to git-log? [ time passes as i read the manpage - the final thing i do when every other measure fails ;-) ] Ah, there's "git-log -R" that would achieve this. The situation still feels a tiny bit inconsistent to me, and that's why my attempt to figure it out intuitively based on my existing practices failed: a) -R is not recognized by git-diff (so i cannot just standardize myself on -R and have to waste neurons on remembering the distinction ;-) b) --reverse has different meaning in git-log and git-diff. Perhaps one solution would be if -R was recognized by git-diff as the meaning of --reverse is an ABI. The extension to the sha1 range specifier would be nice as well, it feels intuitive to me. Hm? Ingo ``` ## Junio C Hamano, 2008-06-20 08:38 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <7v7icko61g.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v7icko61g.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20080620082034.GA24913@elte.hu> ``` Ingo Molnar writes: > a) -R is not recognized by git-diff (so i cannot just standardize > myself on -R and have to waste neurons on remembering the > distinction ;-) Huh? Have you actually tried "git diff -R"? My copy of git 1.0.0 knows about it. What year are you still in ;-)? If you apply the output of git diff -R HEAD^..HEAD to your tree, you can revert the tip commit. It is the same as git diff HEAD..HEAD^ If you want to write a forward diff in an obscure way, you could say git diff -R HEAD..HEAD^ ``` ## Junio C Hamano, 2008-06-20 08:46 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <7v3an8o5mm.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v3an8o5mm.fsf%40gitster.siamese.dyndns.org In-Reply-To: <7v7icko61g.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano writes: > Ingo Molnar writes: > >> a) -R is not recognized by git-diff (so i cannot just standardize >> myself on -R and have to waste neurons on remembering the >> distinction ;-) > > Huh? Have you actually tried "git diff -R"? My copy of git 1.0.0 knows > about it. What year are you still in ;-)? > > If you apply the output of > > git diff -R HEAD^..HEAD > > to your tree, you can revert the tip commit. It is the same as > > git diff HEAD..HEAD^ > > If you want to write a forward diff in an obscure way, you could say > > git diff -R HEAD..HEAD^ By the way, not linking --reverse (traverse the history normally and then show the commits in the reverse order than usual) to -R (show diff in the opposite way while showing the change each commit introduces) allows you to even say "log --reverse -R", which did not come from a conscious design, but being able to say this _is_ a conscious design: $ git fetch j6t $ git log --reverse -p ..j6t/for-junio When I review a branch somebody else offers me, I may want to view the commits on them in reverse order (so that they build a bit by bit on top of my tree), but I _certainly_ do not want to view the patch in reverse! ``` ## Ingo Molnar, 2008-06-20 10:00 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080620100038.GB10704@elte.hu> URL: https://gitlist.dev/e/20080620100038.GB10704%40elte.hu In-Reply-To: <7v3an8o5mm.fsf@gitster.siamese.dyndns.org> ``` * Junio C Hamano wrote: > By the way, not linking --reverse (traverse the history normally and > then show the commits in the reverse order than usual) to -R (show > diff in the opposite way while showing the change each commit > introduces) allows you to even say "log --reverse -R", which did not > come from a conscious design, but being able to say this _is_ a > conscious design: > > $ git fetch j6t > $ git log --reverse -p ..j6t/for-junio > > When I review a branch somebody else offers me, I may want to view the > commits on them in reverse order (so that they build a bit by bit on > top of my tree), but I _certainly_ do not want to view the patch in > reverse! yes, i too do that occasionally (and some of my export/import scripts rely on it in fact), and i was not suggesting to change any existing functionality anyway. Ingo ``` ## Ingo Molnar, 2008-06-20 10:02 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080620100224.GC10704@elte.hu> URL: https://gitlist.dev/e/20080620100224.GC10704%40elte.hu In-Reply-To: <7v7icko61g.fsf@gitster.siamese.dyndns.org> ``` * Junio C Hamano wrote: > Ingo Molnar writes: > > > a) -R is not recognized by git-diff (so i cannot just standardize > > myself on -R and have to waste neurons on remembering the > > distinction ;-) > > Huh? Have you actually tried "git diff -R"? My copy of git 1.0.0 > knows about it. What year are you still in ;-)? yeah, i tried it and somehow messed up so this is a red herring - i'll just use -R from now on :-) the HEAD..^ format suggestion still stands, to express the range from HEAD to HEAD-1. Ingo ``` ## Jakub Narebski, 2008-06-20 10:05 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: URL: https://gitlist.dev/e/m3d4mcmq20.fsf%40localhost.localdomain In-Reply-To: <20080620082034.GA24913@elte.hu> ``` Ingo Molnar writes: > I've got two observations / potential suggestions: > > 1) the SHA1 is duplicated above, is there a way to avoid it? Initially i > tried the obvious extension: > > git-diff --reverse 7def2be1..^ > > But Git didnt recognize that as a valid commit range. There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is documented anywhere, though), so you could have used git diff 7def2be1^! > [ time passes as i read the manpage - the final thing i do when > every other measure fails ;-) ] > > Ah, there's "git-log -R" that would achieve this. I think you should have done this first... -- Jakub Narebski Poland ShadeHawk on #git ``` ## Matthieu Moy, 2008-06-20 11:30 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: URL: https://gitlist.dev/e/vpqiqw42vk6.fsf%40bauges.imag.fr In-Reply-To: <20080620082034.GA24913@elte.hu> ``` Ingo Molnar writes: > 1) the SHA1 is duplicated above, is there a way to avoid it? Initially i > tried the obvious extension: > > git-diff --reverse 7def2be1..^ > > But Git didnt recognize that as a valid commit range. Git may not know how to do it, but since you can omit the .. here, your shell knows: git diff whatever{,^} (BTW, git-foo is being obsoleted in favor of "git foo") -- Matthieu ``` ## Mikael Magnusson, 2008-06-20 13:02 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <237967ef0806200602v6b95939fm2663be849799e2de@mail.gmail.com> URL: https://gitlist.dev/e/237967ef0806200602v6b95939fm2663be849799e2de%40mail.gmail.com In-Reply-To: ``` 2008/6/20 Jakub Narebski : > There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is > documented anywhere, though), so you could have used > > git diff 7def2be1^! > >> [ time passes as i read the manpage - the final thing i do when >> every other measure fails ;-) ] With some grepping, i found this in git-rev-parse, Two other shorthands for naming a set that is formed by a commit and its parent commits exists. r1^@ notation means all parents of r1. r1^! includes commit r1 but excludes its all parents. -- Mikael Magnusson ``` ## Mikael Magnusson, 2008-06-20 13:04 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <237967ef0806200604s469a844l4d33301a60789c1@mail.gmail.com> URL: https://gitlist.dev/e/237967ef0806200604s469a844l4d33301a60789c1%40mail.gmail.com In-Reply-To: <20080620082034.GA24913@elte.hu> ``` 2008/6/20 Ingo Molnar : > > A couple of stupid Git questions (using git-1.5.4.3-2.fc8). > > Sometimes i want to see the reverse diff of a particular commit. > > If i want to see the normal diff i do: > > git-log -1 -p 7def2be1 git show 7def2b1 is a bit easier to type. -- Mikael Magnusson ``` ## Jakub Narebski, 2008-06-20 13:13 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <200806201513.51034.jnareb@gmail.com> URL: https://gitlist.dev/e/200806201513.51034.jnareb%40gmail.com In-Reply-To: <237967ef0806200602v6b95939fm2663be849799e2de@mail.gmail.com> ``` Mikael Magnusson wrote: > 2008/6/20 Jakub Narebski : > >> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is >> documented anywhere, though), so you could have used >> >> git diff 7def2be1^! >> >>> [ time passes as i read the manpage - the final thing i do when >>> every other measure fails ;-) ] > > With some grepping, i found this in git-rev-parse, > > Two other shorthands for naming a set that is formed by a commit and its parent > commits exists. r1^@ notation means all parents of r1. r1^! includes commit r1 > but excludes its all parents. A bit strange is that neither "git rev-parse pu^!" nor "git rev-parse pu^@" work, while the same works with git-rev-list. WTF? -- Jakub Narebski Poland ``` ## Ingo Molnar, 2008-06-20 13:50 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080620135004.GB8135@elte.hu> URL: https://gitlist.dev/e/20080620135004.GB8135%40elte.hu In-Reply-To: ``` * Matthieu Moy wrote: > (BTW, git-foo is being obsoleted in favor of "git foo") hm, can Bash be taught to do command completion on 'git rer', like it is able to do on git-rer ? Ingo ``` ## Ingo Molnar, 2008-06-20 13:52 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080620135236.GC8135@elte.hu> URL: https://gitlist.dev/e/20080620135236.GC8135%40elte.hu In-Reply-To: ``` * Jakub Narebski wrote: > > But Git didnt recognize that as a valid commit range. > > There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is > documented anywhere, though), so you could have used > > git diff 7def2be1^! nice! :-) > > [ time passes as i read the manpage - the final thing i do when > > every other measure fails ;-) ] > > > > Ah, there's "git-log -R" that would achieve this. > > I think you should have done this first... to read the man page? Nobody reads the manuals, except in grave circumstances ;-) (Seriously, i usually try to guess around a lot with shell commands just to figure out new things, and to see how intuitive they are.) Ingo ``` ## Jakub Narebski, 2008-06-20 14:23 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: URL: https://gitlist.dev/e/m34p7ombie.fsf%40localhost.localdomain In-Reply-To: <20080620135004.GB8135@elte.hu> ``` Ingo Molnar writes: > * Matthieu Moy wrote: > > > (BTW, git-foo is being obsoleted in favor of "git foo") > > hm, can Bash be taught to do command completion on 'git rer', like > it is able to do on git-rer ? contrib/completion/git-completion.bash in git repository. I don't know if there are some ready packages[1] for contrib stuff, and git-completion.bash doesn't seem to get packaged with git. [1] RPM packages, because Debian seems to have packaged everything, or almist everything, in a itty-bitty-tiny package(lets) :-P You can always use zsh, which has git completion in package... ;-) > Ingo -- Jakub Narebski "My name is Inigo Montoya. You killed my father prepare to die" (The Princess Bride) ``` ## Ingo Molnar, 2008-06-20 15:38 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080620153859.GA5700@elte.hu> URL: https://gitlist.dev/e/20080620153859.GA5700%40elte.hu In-Reply-To: <20080620153819.GF17373@elte.hu> ``` * Jakub Narebski wrote: > > hm, can Bash be taught to do command completion on 'git rer', > > like it is able to do on git-rer ? > > contrib/completion/git-completion.bash in git repository. works perfectly - thanks for the suggestion! Ingo ``` ## Andreas Ericsson, 2008-06-22 18:52 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <485E9F52.1060706@op5.se> URL: https://gitlist.dev/e/485E9F52.1060706%40op5.se In-Reply-To: <20080620135236.GC8135@elte.hu> ``` Ingo Molnar wrote: > * Jakub Narebski wrote: > >>> But Git didnt recognize that as a valid commit range. >> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is >> documented anywhere, though), so you could have used >> >> git diff 7def2be1^! > > nice! :-) > And for just a single revision, you can do git show -R 7def2be1 -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Ingo Molnar, 2008-06-26 09:37 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080626093726.GA24577@elte.hu> URL: https://gitlist.dev/e/20080626093726.GA24577%40elte.hu In-Reply-To: ``` * Jakub Narebski wrote: > Ingo Molnar writes: > > > * Matthieu Moy wrote: > > > > > (BTW, git-foo is being obsoleted in favor of "git foo") > > > > hm, can Bash be taught to do command completion on 'git rer', like > > it is able to do on git-rer ? > > contrib/completion/git-completion.bash in git repository. btw., i had to turn this off - it made certain types of file completions almost unusable, by adding a 2-3 seconds delay (during which bash would just spin around burning CPU time calculating its completion guesses). and that was on a 3 GHz dual-core box ... so please do not remove the git-* commands, they are really useful. Ingo ``` ## Jakub Narebski, 2008-06-26 11:02 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <200806261302.03952.jnareb@gmail.com> URL: https://gitlist.dev/e/200806261302.03952.jnareb%40gmail.com In-Reply-To: <20080626093726.GA24577@elte.hu> ``` On Thu, 26. Jun 2008, Ingo Molnar wrote: > * Jakub Narebski wrote: >> Ingo Molnar writes: >>> * Matthieu Moy wrote: >>> >>>> (BTW, git-foo is being obsoleted in favor of "git foo") >>> >>> hm, can Bash be taught to do command completion on 'git rer', like >>> it is able to do on git-rer ? >> >> contrib/completion/git-completion.bash in git repository. > > btw., i had to turn this off - it made certain types of file completions > almost unusable, by adding a 2-3 seconds delay (during which bash would > just spin around burning CPU time calculating its completion guesses). Perhaps it would be better when "ceiling dir" feature in git, and configured, so git don't waste time searching for git repositories where there aren't any. > and that was on a 3 GHz dual-core box ... I think this might depend more on filesystem used, and file hierarchy. And also probably on the number of branches... That said, I'm not fully happy with git bash completion[*1*] either: one of complaints is that when completing "filename." on filename with extension (for example to "filename.h") it sometimes treats "filename." as beiginning of "..", and completes to "filename..", even if there no 'filename' ref in repository. > so please do not remove the git-* commands, they are really useful. Well, they are not removed, just moved aside (to address complaints of cluttering $PATH with 130+ programs), and I think that you can always install everything into /usr/bin/, as usual. Although it would be nice to be able to move aside only internal (*--*) commands, or perhaps even internal and plumbing. Footnotes: ========== [*1*] I wonder how zsh git completion fares in comparison. -- Jakub Narebski Poland ``` ## Ingo Molnar, 2008-06-26 11:08 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080626110826.GA25701@elte.hu> URL: https://gitlist.dev/e/20080626110826.GA25701%40elte.hu In-Reply-To: <200806261302.03952.jnareb@gmail.com> ``` * Jakub Narebski wrote: > On Thu, 26. Jun 2008, Ingo Molnar wrote: > > * Jakub Narebski wrote: > >> Ingo Molnar writes: > >>> * Matthieu Moy wrote: > >>> > >>>> (BTW, git-foo is being obsoleted in favor of "git foo") > >>> > >>> hm, can Bash be taught to do command completion on 'git rer', like > >>> it is able to do on git-rer ? > >> > >> contrib/completion/git-completion.bash in git repository. > > > > btw., i had to turn this off - it made certain types of file completions > > almost unusable, by adding a 2-3 seconds delay (during which bash would > > just spin around burning CPU time calculating its completion guesses). > > Perhaps it would be better when "ceiling dir" feature in git, and > configured, so git don't waste time searching for git repositories > where there aren't any. > > > and that was on a 3 GHz dual-core box ... > > I think this might depend more on filesystem used, and file hierarchy. > And also probably on the number of branches... well i wanted to say it's a box fast enough. ext3, kernel tree, -tip repository with 142 local branches and 277 total branches. Ingo ``` ## Nicolas Pitre, 2008-06-26 13:50 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: URL: https://gitlist.dev/e/alpine.LFD.1.10.0806260949010.2979%40xanadu.home In-Reply-To: <200806261302.03952.jnareb@gmail.com> ``` On Thu, 26 Jun 2008, Jakub Narebski wrote: > On Thu, 26. Jun 2008, Ingo Molnar wrote: > > so please do not remove the git-* commands, they are really useful. > > Well, they are not removed, just moved aside (to address complaints > of cluttering $PATH with 130+ programs), and I think that you can > always install everything into /usr/bin/, as usual. Although it would > be nice to be able to move aside only internal (*--*) commands, or > perhaps even internal and plumbing. Or simply add $gitexecdir to your search path. Nicolas ``` ## Junio C Hamano, 2008-06-28 22:08 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <7vk5g9kyap.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk5g9kyap.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20080626093726.GA24577@elte.hu> ``` Ingo Molnar writes: > * Jakub Narebski wrote: > ... >> contrib/completion/git-completion.bash in git repository. > > btw., i had to turn this off - it made certain types of file completions > almost unusable, by adding a 2-3 seconds delay (during which bash would > just spin around burning CPU time calculating its completion guesses). > > and that was on a 3 GHz dual-core box ... > > so please do not remove the git-* commands, they are really useful. The slowness of the completion script (especially the time it takes before it decides to complete pathnames) has been bothering me for some time, so I share Ingo's frustration, but it hasn't got to the point to disable it. After typing: $ git checkout master -- Docu and then hitting the "Tab" key to complete before I see "mentation/", it takes about 2-3 seconds for the first time, and after that it becomes torelable. Is it the command table bootstrapping that is taking this long? I'll be mostly offline for the rest of the day, so you do not have to respond in a hurry. ``` ## Dmitry Potapov, 2008-07-06 16:16 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <37fcd2780807060916h7d8c4e6mba7f30570d527dc3@mail.gmail.com> URL: https://gitlist.dev/e/37fcd2780807060916h7d8c4e6mba7f30570d527dc3%40mail.gmail.com In-Reply-To: ``` On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski wrote: > > There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is > documented anywhere, though), The latter is not exactly a shortcut for the former. You can try it at any merge commit, and you will see different log. For instance, in Git repo: $git rev-list 7ac749c^..7ac749c 7ac749c96d143ba4f76723959892cbaddbe8ed07 006f31d77f3dd5f813557c2839b39b2aaa22b925 53b22a9e45161004ff3260782abc4ee2a5b3e730 872354dcb3ce5f34f7ddb12d2c89d26a1ea4daf0 bc7c73e29cfb38232b5b6b1d1e8d59e7145a9860 $git rev-list 7ac749c^! 7ac749c96d143ba4f76723959892cbaddbe8ed07 So, I believe, rev^! means --first-parent rev^..rev Dmitry ``` ## Junio C Hamano, 2008-07-06 20:04 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <7vprpqdbjx.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vprpqdbjx.fsf%40gitster.siamese.dyndns.org In-Reply-To: <37fcd2780807060916h7d8c4e6mba7f30570d527dc3@mail.gmail.com> ``` "Dmitry Potapov" writes: > On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski wrote: >> >> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is >> documented anywhere, though), > > The latter is not exactly a shortcut for the former. You can try it at any > merge commit, and you will see different log. For instance, in Git repo: > ... > So, I believe, rev^! means --first-parent rev^..rev Not quite. From Documentation/git-rev-parse.txt: SPECIFYING RANGES ----------------- Two other shorthands for naming a set that is formed by a commit and its parent commits exists. `r1{caret}@` notation means all parents of `r1`. `r1{caret}!` includes commit `r1` but excludes its all parents. ``` ## Dmitry Potapov, 2008-07-06 20:39 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080706203951.GB1721@dpotapov.dyndns.org> URL: https://gitlist.dev/e/20080706203951.GB1721%40dpotapov.dyndns.org In-Reply-To: <7vprpqdbjx.fsf@gitster.siamese.dyndns.org> ``` On Sun, Jul 06, 2008 at 01:04:18PM -0700, Junio C Hamano wrote: > Two other shorthands for naming a set that is formed by a commit > and its parent commits exists. `r1{caret}@` notation means all > parents of `r1`. `r1{caret}!` includes commit `r1` but excludes > its all parents. So, I would say that rev^! is shorthand for rev^@..rev, but it does not actually work: git rev-list 7ac749c^@..7ac749c fatal: ambiguous argument '7ac749c^@..7ac749c': unknown revision or path not in the working tree. yet "^rev^@ rev" syntax does: git rev-list ^7ac749c^@ 7ac749c 7ac749c96d143ba4f76723959892cbaddbe8ed07 Is it a bug or feature? Puzzled... Dmitry ``` ## Junio C Hamano, 2008-07-06 22:33 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <7vbq1ad4nn.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vbq1ad4nn.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20080706203951.GB1721@dpotapov.dyndns.org> ``` Dmitry Potapov writes: > On Sun, Jul 06, 2008 at 01:04:18PM -0700, Junio C Hamano wrote: >> Two other shorthands for naming a set that is formed by a commit >> and its parent commits exists. `r1{caret}@` notation means all >> parents of `r1`. `r1{caret}!` includes commit `r1` but excludes >> its all parents. > > So, I would say that rev^! is shorthand for rev^@..rev, but it does not > actually work: > > git rev-list 7ac749c^@..7ac749c > fatal: ambiguous argument '7ac749c^@..7ac749c': unknown revision or path > not in the working tree. > > yet "^rev^@ rev" syntax does: > > git rev-list ^7ac749c^@ 7ac749c > 7ac749c96d143ba4f76723959892cbaddbe8ed07 > > Is it a bug or feature? > > Puzzled... After reading these paragraphs from "SPECIFYING RANGES": History traversing commands such as 'git-log' operate on a set of commits, not just a single commit. To these commands, specifying a single revision with the notation described in the previous section means the set of commits reachable from that commit, following the commit ancestry chain. To exclude commits reachable from a commit, a prefix `{caret}` notation is used. E.g. "`{caret}r1 r2`" means commits reachable from `r2` but exclude the ones reachable from `r1`. This set operation appears so often that there is a shorthand for it. "`r1..r2`" is equivalent to "`{caret}r1 r2`". It is the difference of two sets (subtract the set of commits reachable from `r1` from the set of commits reachable from `r2`). it is obvious to me that the third paragraph talks about r1 that is a single rev (refer to SPECIFYING REVISIONS section, which does _NOT_ talk about rev^@ nor rev^!) and r2 that similarly is another single rev. So I think it is fairly clear that your "r^@..r" example is nonsense. But perhaps these paragraphs need to be further reworded to avoid the confusion. I dunno. ``` ## Dmitry Potapov, 2008-07-07 04:01 Subject: Re: [q] git-diff --reverse 7def2be1..7def2be1^ Message-ID: <20080707040131.GC1721@dpotapov.dyndns.org> URL: https://gitlist.dev/e/20080707040131.GC1721%40dpotapov.dyndns.org In-Reply-To: <7vbq1ad4nn.fsf@gitster.siamese.dyndns.org> ``` On Sun, Jul 06, 2008 at 03:33:16PM -0700, Junio C Hamano wrote: > Dmitry Potapov writes: > > > git rev-list 7ac749c^@..7ac749c > > fatal: ambiguous argument '7ac749c^@..7ac749c': unknown revision or path > > not in the working tree. > > > > yet "^rev^@ rev" syntax does: > > > > git rev-list ^7ac749c^@ 7ac749c > > 7ac749c96d143ba4f76723959892cbaddbe8ed07 > > > > Is it a bug or feature? > > > > Puzzled... > > After reading these paragraphs from "SPECIFYING RANGES": > > History traversing commands such as 'git-log' operate on a set > of commits, not just a single commit. To these commands, > specifying a single revision with the notation described in the > previous section means the set of commits reachable from that > commit, following the commit ancestry chain. > > To exclude commits reachable from a commit, a prefix `{caret}` > notation is used. E.g. "`{caret}r1 r2`" means commits reachable > from `r2` but exclude the ones reachable from `r1`. > > This set operation appears so often that there is a shorthand > for it. "`r1..r2`" is equivalent to "`{caret}r1 r2`". It is > the difference of two sets (subtract the set of commits > reachable from `r1` from the set of commits reachable from > `r2`). > > it is obvious to me that the third paragraph talks about r1 that is a > single rev (refer to SPECIFYING REVISIONS section, which does _NOT_ talk > about rev^@ nor rev^!) and r2 that similarly is another single rev. So I > think it is fairly clear that your "r^@..r" example is nonsense. I think both second and third paragraphs talk about r1 as a single revision. Yet, it is allowed to use "^r^@ r", and it works fine while you cannot use "r^@..r". Of course, this behavior does not contradict documentation, as it says _nothing_ about what will happen if you use "r^@" instead of r1. That is why asked whether it is a bug or feature. It still escapes me though, why you consider "r^@..r" as nonsense while "^r^@ r" as correct syntax. Not that I am trying to argue with how it should work, but I am just trying to understand your logic here. Dmitry ```