On Sun, Jan 22, 2012 at 04:57:52PM +0000, Mikolas wrote: > 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 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). > So my questions are > 1) Is there some way how to tell status to tell me *why* the files are marked > as modified? 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). > 2) Is it normal that git status behaves differently in different directories? No. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html