threads / bug / 4022

Bug in git log

Subject: Bug in git log

## tl;dr

4 messages between May 2, 2006 and May 2, 2006.

replies: 3people: 3as markdown or json

Matthias Kestenholz· May 2, 2006, 07:51 UTC · lore

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

Junio C Hamano· May 2, 2006, 08:24 UTC · re: Matthias Kestenholz · lore

Re: Bug in git log

Matthias Kestenholz <lists@irregular.ch> writes:

Show 11 quoted lines

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

Show 5 quoted lines

> $ 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?

Matthias Kestenholz· May 2, 2006, 13:41 UTC · re: Junio C Hamano · lore

Re: Bug in git log

* Junio C Hamano (junkio@cox.net) wrote:

Show 6 quoted lines

> [...]
> 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

Linus Torvalds· May 2, 2006, 15:26 UTC · re: Matthias Kestenholz · lore

Re: Bug in git log

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}