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

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

Ingo Molnar <mingo@elte.hu> writes:

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 <gitster@pobox.com> writes:

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!

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

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

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

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

Ingo Molnar <mingo@elte.hu> writes:

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^!
 

I think you should have done this first...

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

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 wrote:

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 <jnareb@gmail.com> wrote:

nice! :-)

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

Ingo Molnar wrote:

And for just a single revision, you can do

	git show -R 7def2be1

On Fri, Jun 20, 2008 at 2:05 PM, Jakub Narebski <jnareb@gmail.com> wrote:

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

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

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.

On Sun, Jul 06, 2008 at 01:04:18PM -0700, Junio C Hamano wrote:

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

Dmitry Potapov <dpotapov@gmail.com> writes:

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.

On Sun, Jul 06, 2008 at 03:33:16PM -0700, Junio C Hamano wrote:

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

Ingo Molnar <mingo@elte.hu> writes:

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 Moy <Matthieu.Moy@imag.fr> wrote:

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

	Ingo

Ingo Molnar <mingo@elte.hu> writes:

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... ;-)
 

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

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

On Thu, 26. Jun 2008, Ingo Molnar wrote:

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.

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.

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 <jnareb@gmail.com> wrote:

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

On Thu, 26 Jun 2008, Jakub Narebski wrote:

Or simply add $gitexecdir to your search path.

Nicolas

Ingo Molnar <mingo@elte.hu> writes:

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>

2008/6/20 Ingo Molnar <mingo@elte.hu>:

git show 7def2b1 is a bit easier to type.

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

works perfectly - thanks for the suggestion!

	Ingo