How to compare different files in different branches

Hello!

I want to compare 'configure.in' from the master branch with 'configure.ac' from the gpm-2-dev branch.

What I tried:

% git-diff master..gpm-2-dev configure.ac fatal: ambiguous argument 'configure.ac': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

# ok, correct, there is no configure.ac in master # But not what I want.

% git-diff master..gpm-2-dev configure.in

# shows that the file does not exist in gpm-2-dev. Correct. # But not what I want.

Strange ist: % git-diff --summary master...gpm-2-dev and % git-diff --stat master...gpm-2-dev do not show the rename.

But using

% git log -Sconfigure gpm-2-dev

I find the rename in commit 5fe49d36d775af47c08bb9a0c0beabef609bba20.

Now I could do 

% git-checkout master configure.in

in the gpm-2-dev branch and manually compare it with diff. But - you guessed it - is not what I want.

I really think git can do that, but currently I do not see the right way. So any idea on how to do that?

Sincerly

Nico

P.S.: Please cc on reply.

On Fri, Jun 6, 2008 at 1:24 PM, Nico -telmich- Schottelius <nico-git-20080606@schottelius.org> wrote:

How about git diff master:configure.in gm-2-dev:configure.ac ?

Nico -telmich- Schottelius <nico-git-20080606@schottelius.org> writes:

[...]

 $ git diff master:configure.in gpm-2-dev:configure.ac

See "Specifying revisions" in git-rev-list(1); I think it can be also found in other places, but I'm not sure. git-show(1) refers to this section when describing <object> option.

Jakub Narebski <jnareb@gmail.com> writes:

 $ git diff -M master gpm-2-dev -- configure.in configure.ac

should also work.

Nico -telmich- Schottelius wrote (2008-06-06 14:24 +0200):

You could do:

  $ git diff master:configure.in gpm-2-dev:configure.ac

In general form it means:

  $ git diff <commit1>:<path1> <commit2>:<path2>

You can also view directories and files similar way:

  $ git show <commit>:<path>

And <commit> can be anything that refers to a commit, e.g. a branch name, a tag, SHA1 or a relative pointer like master^2~5.

Thank you all for your fast answers!

I must confess I've overseen -M, as I saw --no-renames and searched for --renames.

Teemu Likonen [Fri, Jun 06, 2008 at 03:35:39PM +0300]:

Very nice syntax, somehow guessed that this is available, but didn't try... my fault.

Perhaps we should reference git-rev-list(1) from git-diff(1), too?

Sincerly

Nico

Nico -telmich- Schottelius <nico-git-20080606@schottelius.org> writes:

This is just the standard syntax to name blob _anywhere_, so we should not hide it in git-rev-list(1) but somewhere people would read before reading any "technical manual" material, perhaps in the tutorial and git(1).

On Jun 8, 2008, at 2:51, Junio C Hamano wrote:

+1! A "how to specify files and revisions" tutorial with tips, tricks and examples would be great.

Since it's much more powerful in git than in other SCMs, this is one of the larger bits of things to learn.

  - ask

Hello dear git list!

The following information was submitted to me by Frederik and is forwarded to the list, because he's no mail access right now:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Using "git-svn dcommit", files or folders named ".svn" can be committed to the Subversion repository.
This breaks the SVN repo - e.g. "svn update" results in the following error:
    svn: Failed to add directory '.svn': object of the same name already exists

Ideally, the SVN server would reject such a commit.
However, if I interpret the following issues correctly, Subversion doesn't want to handle this server-side:
    http://subversion.tigris.org/issues/show_bug.cgi?id=1068
    (also: http://subversion.tigris.org/issues/show_bug.cgi?id=1065)

Since this is potentially a very critical issue, I suggest git-svn dcommit check and filter for such occurrences. Alternatively, a prominent warning could be added to the relevant git-svn commands.

Details:
    git version 1.5.4.3
    svn version 1.4.6 (r28521)
    Plattform: Ubuntu 8.04 Hardy Heron
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Sincerly

Nico

PS: Please CC him and me on reply.

Sorry about that - I did search the archives before having this posted, but that didn't come up with anything (the search functionality is quite limited though).

Not a bad idea - but this still requires manual intervention (and thus awareness), which doesn't solve the potential destructiveness of this issue.

The website is up again. However, there doesn't seem to be a dedicated bug tracking tool.

-- F.