[q] git-diff --reverse 7def2be1..7def2be1^

[q] git-diff --reverse 7def2be1..7def2be1^

[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

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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> 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^

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Ingo Molnar <mingo@elte.hu> 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!

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Ingo Molnar]

* Junio C Hamano <gitster@pobox.com> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Ingo Molnar]

* Junio C Hamano <gitster@pobox.com> wrote:

> Ingo Molnar <mingo@elte.hu> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Jakub Narebski]

Ingo Molnar <mingo@elte.hu> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Matthieu Moy]

Ingo Molnar <mingo@elte.hu> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Mikael Magnusson]

2008/6/20 Jakub Narebski <jnareb@gmail.com>:

> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Mikael Magnusson]

2008/6/20 Ingo Molnar <mingo@elte.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

git show 7def2b1 is a bit easier to type.

-- 
Mikael Magnusson

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Jakub Narebski]

Mikael Magnusson wrote:
> 2008/6/20 Jakub Narebski <jnareb@gmail.com>:
> 
>> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Ingo Molnar]

* Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

> (BTW, git-foo is being obsoleted in favor of "git foo")

hm, can Bash be taught to do command completion on 'git rer<tab>', like 
it is able to do on git-rer<tab> ?

	Ingo

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Ingo Molnar]

* Jakub Narebski <jnareb@gmail.com> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Jakub Narebski]

Ingo Molnar <mingo@elte.hu> writes:

> * Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> 
> > (BTW, git-foo is being obsoleted in favor of "git foo")
> 
> hm, can Bash be taught to do command completion on 'git rer<tab>', like 
> it is able to do on git-rer<tab> ?

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)

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Ingo Molnar]

* Jakub Narebski <jnareb@gmail.com> wrote:

> > hm, can Bash be taught to do command completion on 'git rer<tab>',
> > like it is able to do on git-rer<tab> ?
>
> contrib/completion/git-completion.bash in git repository.

works perfectly - thanks for the suggestion!

	Ingo

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Andreas Ericsson]

Ingo Molnar wrote:
> * Jakub Narebski <jnareb@gmail.com> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Ingo Molnar]

* Jakub Narebski <jnareb@gmail.com> wrote:

> Ingo Molnar <mingo@elte.hu> writes:
> 
> > * Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > 
> > > (BTW, git-foo is being obsoleted in favor of "git foo")
> > 
> > hm, can Bash be taught to do command completion on 'git rer<tab>', like 
> > it is able to do on git-rer<tab> ?
> 
> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Jakub Narebski]

On Thu, 26. Jun 2008, Ingo Molnar wrote:
> * Jakub Narebski <jnareb@gmail.com> wrote:
>> Ingo Molnar <mingo@elte.hu> writes:
>>> * Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>>> 
>>>> (BTW, git-foo is being obsoleted in favor of "git foo")
>>> 
>>> hm, can Bash be taught to do command completion on 'git rer<tab>', like 
>>> it is able to do on git-rer<tab> ?
>> 
>> 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 "<rev1>..<rev2>", 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Ingo Molnar]

* Jakub Narebski <jnareb@gmail.com> wrote:

> On Thu, 26. Jun 2008, Ingo Molnar wrote:
> > * Jakub Narebski <jnareb@gmail.com> wrote:
> >> Ingo Molnar <mingo@elte.hu> writes:
> >>> * Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> >>> 
> >>>> (BTW, git-foo is being obsoleted in favor of "git foo")
> >>> 
> >>> hm, can Bash be taught to do command completion on 'git rer<tab>', like 
> >>> it is able to do on git-rer<tab> ?
> >> 
> >> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Nicolas Pitre]

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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> writes:

> * Jakub Narebski <jnareb@gmail.com> 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?

<offtopic> I'll be mostly offline for the rest of the day, so you do not
have to respond in a hurry. </offtopic>

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Dmitry Potapov]

On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski <jnareb@gmail.com> 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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Junio C Hamano]

"Dmitry Potapov" <dpotapov@gmail.com> writes:

> On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski <jnareb@gmail.com> 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.

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Dmitry Potapov]

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

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Junio C Hamano]

Dmitry Potapov <dpotapov@gmail.com> 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.

Re: [q] git-diff --reverse 7def2be1..7def2be1^

[Dmitry Potapov]

On Sun, Jul 06, 2008 at 03:33:16PM -0700, Junio C Hamano wrote:
> Dmitry Potapov <dpotapov@gmail.com> 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