Re: [PATCH] difftool: add support for an extended revision syntax

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 27, 2009, 15:59 UTC
Message-ID: <m33acz2byv.fsf@localhost.localdomain>
In-Reply-To: <1237803348-9329-1-git-send-email-davvid@gmail.com>

David Aguilar <davvid@gmail.com> writes:

Show 17 quoted lines

> This adds an extended revision syntax to git-difftool.
> Users often ask "how do I compare a file against its
> previous version" and the answer is typically a combination
> of 'git log <file>' and 'git difftool <sha1> <sha1> <file>'.
> 
> This makes answering that question considerably easier.
> Users can now simply say:
> 
> 	$ git difftool <file>~
> 
> to compare <file> in the worktree against its
> previous version, and:
> 
> 	$ git difftool <file>~2 <file>~
> 
> to compare <file> from 2 versions ago to <file>'s
> previous version, etc.

Because <rev>~<n> means (see git-rev-parse(1) for example) n-th parent in _first parent_ line, then <file>~<n> should also use first-parent line, otherwise you invite confusion.

Also I am not sure about the syntax, as there are no restrictions on
filenames, and filenames can contain '~'.  Perhaps (proposed in this
thread) ~<n>:<file> == 
  "$(git rev-list -n <n> --first-parent HEAD -- <file> | tail):<file>"

But this might be mistaken for HEAD~<n>:<file>, which can be something
else...

Show 10 quoted lines

> The extended revision syntax also expands revisions
> that are suffixed with '!' as a convenient way to
> see commit diffs.  Specifying only '!' is equivalent
> to specifying 'HEAD!'.
> 
> This makes the following statements equivalent:
> 
> 	$ git difftool !
> 	$ git difftool HEAD!
> 	$ git difftool HEAD~ HEAD

Errr... there already exists such syntax, and it is called HEAD^! (if git-difftool can accept a..b revision specification)... or not, as git-rev-parse(1) states:

  r1^! includes commit r1 but excludes all of its parents.

So depending on how "r1 --not r1^" and "r1 --not r1^1 r1^2" is interpreted by diff (which accpets points, not ranges) it might be, or might be not what you wanted by introducying '!' / <rev>:! specification...

-- 
Jakub Narebski
Poland
ShadeHawk on #git