git blame shows wrong "Not commited yet" entries

git blame shows wrong "Not commited yet" entries

[Thomas Ackermann]

 
Hi,

I am using MsysGit 1.7.11 on WinXP 32 bit and experience the folllowing strange behaviour:
 
For a file like "File.txt" in the repo, "git blame file.txt" (note the lower case)
shows "Not commited yet" for every single line in the file. 
"git blame File.txt" (correct upper case spelling) gives the correct output.
"core.ignorecase" is "true" so this behaviour is not what I expected.

Is this a bug in MsysGit or some kind of intended behaviour (or bug) in Git?


---
Thomas

Re: git blame shows wrong "Not commited yet" entries

[Junio C Hamano]

Thomas Ackermann <th.acker66@arcor.de> writes:

> I am using MsysGit 1.7.11 on WinXP 32 bit and experience the folllowing strange behaviour:
>  
> For a file like "File.txt" in the repo, "git blame file.txt" (note the lower case)
> shows "Not commited yet" for every single line in the file. 
> "git blame File.txt" (correct upper case spelling) gives the correct output.
> "core.ignorecase" is "true" so this behaviour is not what I expected.

What happens when you do this?

	$ echo garbage >no-such-file-tracked.txt
        $ git blame no-such-file-tracked.txt

If you see everything attributed to the working tree file, I _think_
you are seeing exactly the same thing.  As far as your repository
history is concerned, "file.txt" is never tracked ("File.txt" is),
and when Git asks the contents for "file.txt" in the working tree,
Windows case insensitive filesystem gives it the contents of
"File.txt" instead, all lines in which is initially attributed to
the working tree.  When blame tries to pass the blame around to the
commit at HEAD and down the history, it never finds "file.txt", so
all the blame is given to this phamtom contents from "File.txt"
Windows gave you as if it were stored in "file.txt", which does not
really exist.

An obvious workaround is to say "git blame File.txt".  You might be
able to patch MsysGit so that "git blame file.txt" errors out when
it does not find such a path in the HEAD commit, though.

Aw: Re: git blame shows wrong "Not commited yet" entries

[Thomas Ackermann]

You are right but as I mentioned in my posting I am using "core.ignorecase=true"
so I expected "file.txt" and "File.txt" to be treated the same.

The man-page for git-config says:
"core.ignorecase
If true, this option enables various workarounds to enable git to work better on filesystems that are not case sensitive, like FAT.
For example, if a directory listing finds "makefile" when git expects "Makefile", git will assume it is really the same file, 
and continue to remember it as "Makefile"."

So "various workarounds" does _not_ mean that _all_ filenames are processed modulo upper/lower case, or?


---
Thomas

Re: Aw: Re: git blame shows wrong "Not commited yet" entries

[Junio C Hamano]

Thomas Ackermann <th.acker66@arcor.de> writes:

> The man-page for git-config says:
> "core.ignorecase
> If true, this option enables various workarounds to enable git to
> work better on filesystems that are not case sensitive, like FAT.
> For example, if a directory listing finds "makefile" when git
> expects "Makefile", git will assume it is really the same file,
> and continue to remember it as "Makefile"."
>
> So "various workarounds" does _not_ mean that _all_ filenames are
> processed modulo upper/lower case, or?

Keywords in that paragraph include "various" (not all) and "better"
(not perfectly), and the most important one is "when git expects".

When running "git add file.txt" with "File.txt" in the index, git
expects "File.txt", but the ignorecase logic makes git assume they
are the same, and add content from "file.txt" as "File.txt".

And "git blame $path" probably should expect $path is something that
appear in the tree of HEAD; apparently it does not.

Patches welcome.

Re: Aw: Re: git blame shows wrong "Not commited yet" entries

[Martin von Zweigbergk]

On Fri, Aug 31, 2012 at 10:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> And "git blame $path" probably should expect $path is something that
> appear in the tree of HEAD; apparently it does not.

That probably makes sense. For anyone deciding to implement that, note
that "git blame -C [-C [-C]] $path" should probably not expect the
same, so the following still works.

cp COPYING COPY
git blame -C -C -C COPY

Btw, why isn't "-C -C -C" the same as "-CCC"? Should it?