What does "modified" in git status mean?

I am using git version 1.7.5.1 under cygwin and I'm getting behavior that I'm not understanding.

When I do 'git status' in the root directory of the repository, it shows no difference. Once I cd to a subdirectory, it starts showing modifications. However, 'git diff' shows nothing.

So it looks something like this: $ git status # On branch master nothing to commit (working directory clean)

$ cd foo $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: ../foo/bar

$ git diff $

I put the following in my gitconfig but that doesn't seem to be doing much.
[core]
       trustctime = false
       autocrlf = input

So my questions are 
1) Is there some way how to tell status to tell me *why* the files are marked 
as modified?
2) Is it normal that git status behaves differently in different directories?

--mikolas

In message <loom.20120122T174204-274@post.gmane.org>, Mikolas writes:

    1) Is there some way how to tell status to tell me *why* the files
    are marked as modified?

Not as such. However, I do have a script which, when run from the root of the working directory, manually compares the on-disk files to what is checked into git. This would detect any whitespace or smudge related changes, or of course any normal user changes.

git ls-tree --name-only -r HEAD | while read path; do if [ ! -f "$path" ]; then continue; fi; sha1=`git show "HEAD:$path" | sha1sum | awk '{print $1;}'`; sha2=`sha1sum "$path" | awk '{print $1;}'`; if [ $sha1 != $sha2 ]; then echo "<$sha1> <$sha2> $path"; fi; done

    2) Is it normal that git status behaves differently in different directories?

I would say not, but perhaps you have a .gitattributes in that directory? (Which would be a bug) Could you try with a more recent version of git?

					-Seth Robertson

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/22/2012 11:57 AM, Mikolas wrote:

autocrlf is basically broken, don't use it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPHb4EAAoJEJrBOlT6nu75NmsIALPYuRTdGPLigxmiAWfH4e/i d516AR8AgkWtJzK3TbaD2HxgnQK9dmWYysppT7WR2SetrBrpsEUvQnw0b3jUewkb lL97cEcDfiYbKXnkpfHRtAawUIXhrQeT/8XpOrvc7d8wPCWt4Zd7hrLo3TTuBGmN tQcJtUqPwxreUYWOR5dPMV3oaeclptavEoeGc+2BlTiAuti6aw89G7lRvgVZQDGr y0uCL4QIyOuMU9xUaeiFm/pCqY5MWSTs6Nv3mnAiw6PwK+aR1OcUkJjRw6dM6xWY 7futPNLEph8fptltaLhzMoeSzct3vNd+Al7synmOTh8bGitJeyaiCZOR55CG/eY= =i8Zy -----END PGP SIGNATURE-----

On Sun, Jan 22, 2012 at 04:57:52PM +0000, Mikolas wrote:

Modified files appearing only in some calls to status is definitely odd, and may be a bug. How close is this to your actual invocation?

In particular, if "foo/bar" is modified, and you do "cd foo && git status", then the relative path shown by "git status" should be simply "bar", not "../foo/bar". If you did "cd other && git status", then I would expect it to say "../foo/bar".

So was the directory you entered the same as the one that contains the (supposedly) modified file, yielding the output above?

If that is the case, then I might suspect it has to do with path normalization and case sensitivity. It might be worth seeing if you can reproduce the problem with a more recent version of git. In particular, v1.7.8 and later shipped with my 2548183 (fix phantom untracked files when core.ignorecase is set, 2011-10-06), which fixes some weird bugs surrounding case-insensitive file lookup.

(Actually, even if that is not the case, it would be worth upgrading and seeing if the bug is reproducible).

Typically you would ask "diff" for more details. But since "diff" is not reporting anything, that isn't helpful (and is probably indicative of a bug).

No.

-Peff