Bug in git log

Bug in git log

[Matthias Kestenholz]

Hello list,

I found a bug in the new builtin git log which I am unable to fix
myself.

Inside your git source directory, do:

First bug using old whatchanged script (not builtin version)

$ ./git-whatchanged.sh -- unresolve.c
fatal: ambiguous argument 'unresolve.c': unknown revision or
filename
Use '--' to separate filenames from revisions

$ ./git-whatchanged.sh -- -- unresolve.c
[...] gives the expected output

$ git log -- unresolve.c
$ git log -- -- unresolve.c
$ git whatchanged -- unresolve.c

both give no output.

I checked the argument parsing stage and everything seemed sane (the
second double-dash was not necessary anymore)

However, the following works as expected:

$ git log -- git-log.sh

It seems that the problem shows only if there was no commit
modifying the asked-for file. unresolve.c is introduced in commit
ec167793d84ba7b765e1eb71b0257ce7baca2d26 and removed in the
subsequent commit 2bd452d3b9f62ecc3406307cd6a5553856d21ff2 and is
never modified.

/Matthias


-- 
:wq

Re: Bug in git log

[Junio C Hamano]

Matthias Kestenholz <lists@irregular.ch> writes:

> Inside your git source directory, do:
>
> First bug using old whatchanged script (not builtin version)
>
> $ ./git-whatchanged.sh -- unresolve.c
> fatal: ambiguous argument 'unresolve.c': unknown revision or
> filename
> Use '--' to separate filenames from revisions
>
> $ ./git-whatchanged.sh -- -- unresolve.c
> [...] gives the expected output

That indeed sounds funny.  I was hoping to see it myself but did
not reproduce for me X-<.

> $ git log -- unresolve.c
> $ git log -- -- unresolve.c
> $ git whatchanged -- unresolve.c
>
> both give no output.

I do not have an older version between 0.99.9m and 1.3.1, but
1.3.1 (the current stale release) does not seem to have this
"double dash" problem.  Neither the tonight's "master" version
(746437) nor "next".

We used to have a build problem where we forgot to remove
libgit.a and an old object from the archive was used by
mistake.  Could you try rm -f libgit.a and rebuild your git to
see if it helps?

Re: Bug in git log

[Matthias Kestenholz]

* Junio C Hamano (junkio@cox.net) wrote:
> [...]
> We used to have a build problem where we forgot to remove
> libgit.a and an old object from the archive was used by
> mistake.  Could you try rm -f libgit.a and rebuild your git to
> see if it helps?
> 

Ok I did that. I also removed all files which were installed by
'make install' and did a complete rebuild and install of the current
master branch. My git version is now 1.3.1.g7464

The "double dash" problem is not a big deal since it only happens
with the deprecated shellscript-version of whatchanged.

Does anyone get some output with the following command? That was the
bug I tried to report (sorry for my bad/convoluted english)

$ git log -- unresolve.c

-- 
:wq

Re: Bug in git log

[Linus Torvalds]

On Tue, 2 May 2006, Matthias Kestenholz wrote:
> 
> The "double dash" problem is not a big deal since it only happens
> with the deprecated shellscript-version of whatchanged.

Simple enough to fix. Appended.

The problem was that "git-rev-parse --no-flags --no-revs" will show _just_ 
the filenames from the argument list. That means that it will also remove 
the "--" from the original. That's all well and proper, but 
git-whatchanged had a bug, and it wouldn't separate the filename arguments 
from the flags by adding its own "--".

That bug didn't matter back when we didn't check the parsing all that 
carefully. It does now.

> Does anyone get some output with the following command? That was the
> bug I tried to report (sorry for my bad/convoluted english)
> 
> $ git log -- unresolve.c

Now, this returns empty, and it actually does that for a reason.

Along the main path, "unresolve.c" has never existed. The modern 
"git-whatchanged" (and "git log") is a bit different from the old 
big-whatchanged.

The old git-whatchanged would go through _every_ commit, because it 
literally did

	git-rev-list | git-diff-tree --stdin -- <paths>

and thus the revision list was generated without _any_ regard for the 
paths - and every single commit shows up, whether it is relevant or not.

The new revision is based on the revision parsing thing, and the semantics 
are a bit different: it semantically does the equivalent of

	git-rev-list <paths> | git-diff-tree --stdin -- <paths>

which limits the revision list too on the paths.

And yes, "git log" does the same.

See the discussion a few weeks ago about "path limiting broken", and my 
patch that suggested a "--no-prune-merges" flag:

	http://www.gelato.unsw.edu.au/archives/git/0604/19180.html

which gives more of an explanation.

		Linus

--
diff --git a/git-whatchanged.sh b/git-whatchanged.sh
index 1fb9feb..bb73cff 100755
--- a/git-whatchanged.sh
+++ b/git-whatchanged.sh
@@ -24,5 +24,5 @@ rev_list_args=$(git-rev-parse --sq --def
 diff_tree_args=$(git-rev-parse --sq --no-revs --no-flags "$@") &&
 
 eval "git-rev-list $count $rev_list_args" |
-eval "git-diff-tree --stdin --pretty -r $diff_tree_flags $diff_tree_args" |
+eval "git-diff-tree --stdin --pretty -r $diff_tree_flags -- $diff_tree_args" |
 LESS="$LESS -S" ${PAGER:-less}