Files that cannot be added to the index

Can anyone guess what's going on when I have a modified file that shows up in `git status`, but the file cannot be added to the index (or committed)? `git add FILE` does nothing, the file still shows as modified but not added in `git status`.

I have two different repos that have each developed this problem with two different files. I don't know how it happened. The problem occurs wherever the repos are cloned. Even if I delete the local copy (where I'm seeing the problem) and clone the repo again from elsewhere, problem persists.

seanh venit, vidit, dixit 26.08.2011 14:26:

A log of your commands (or access to the repo) would help diagnose that, along with information about the system and the git version.

Do you "clone" by making a copy, by any chance?

Michael

Unfortunately I can't share the repos, but I've pasted actual output showing the problem below. I'm using git version 1.7.4.4 on OSX Lion, from macports. (I was having the problem on Snow Leopard too.) I am using `git clone` to make the clone, but it's possible that at some point the repo was moved or copied with things like mv, cp, rsync, maybe moving across different filesystems.

seanh@sooty-2:~ % cd /tmp seanh@sooty-2:/tmp % git clone ~/Dotfiles/home Cloning into home... done. seanh@sooty-2:/tmp % cd home seanh@sooty-2:/tmp/home % 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: Text/LOG.txt # no changes added to commit (use "git add" and/or "git commit -a") seanh@sooty-2:/tmp/home % git diff

On Fri, Aug 26, 2011 at 10:59:19PM +0200, seanh wrote:

Not sure if this is your problem exactly but awhile back I ran into something similar to what you describe and tracked it down to the fact that my filesystem was case insensitive. i.e.

  $ git clone git://github.com/sruffell/dahdi-linux
  Cloning into dahdi-linux...
  done.

  $ cd dahdi-linux/
  $ ls
  LICENSE      Makefile     UPGRADE.txt  drivers
  LICENSE.LGPL README       build_tools  include

  $ git ls-files -m
  $ rm Makefile 
  $ touch makefile
  $ git add makefile 
  $ git ls-files -m
  Makefile

  $ git commit
  # 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:   Makefile
  #
  no changes added to commit (use "git add" and/or "git commit -a")

  $ git add makefile 
  $ git commit
  # 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:   Makefile
  #
  no changes added to commit (use "git add" and/or "git commit -a")

On Fri, Aug 26, 2011 at 04:12:33PM -0500, Shaun Ruffell wrote:

I think both of you may be seeing the same bug I tracked down here:

  http://thread.gmane.org/gmane.comp.version-control.git/173612/focus=174634

Does the patch from the very end of the thread solve the problem for you? I should probably clean it up for inclusion in git.

-Peff

On Sat, Aug 27, 2011 at 02:07:18AM -0400, Jeff King wrote:

I don't think it's the same problem. For me the problem does not occur with any git repo, only with two repos in particular. Also, the output is not different every time, there are two files in particular that always show up with phantom modifications in git status and git diff.

On Sat, Aug 27, 2011 at 02:07:18AM -0400, Jeff King wrote:

I was going to apply the patch and see what happens, however when I built and tested 1.7.6 as a baseline I no longer could reproduce the issue.

  $ git commit -m "Makefile"
  [master a931b27] Makefile
   1 files changed, 0 insertions(+), 222 deletions(-)
   delete mode 100644 Makefile
   create mode 100644 makefile
  $ git ls-files -m

The previous version I had installed from one of the OSX package managers (not sure if it was fink or Macports) was 1.6.5.3.

NOTE: I had to compile git from source like "NO_FINK=1 make" in
order to avoid the "ld: warning: in /sw/lib/libiconv.dylib, file is
not of required architecture" error message.

So, in summary, it looks like this is fixed.

Thanks, Shaun

On Sat, Aug 27, 2011 at 01:40:09PM -0500, Shaun Ruffell wrote:

Actually, after playing with it a little more on OSX, I think it was just operator error on my part and that, for this, the versions are behaving the same.

Adding a non-existent file produces an error:
  $ git add adjaskdj
  fatal: pathspec 'adjaskdj' did not match any files

Adding a file that is on the filesystem but only differs in case with a file in the index silently fails:

  $ mv Makefile makefile
  $ echo "hello" >> makefile
  $ git ls-files -m
  Makefile
  $ git add makefile

And then when you try to commit the file you just added it fails:

  $ git commit
  # 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:   Makefile
  #
  no changes added to commit (use "git add" and/or "git commit -a")

Adding a file that is in the index, but only differs by case with a file in the filesystem works:

  $ git add Makefile
  $ git commit -m "test"
  [master 8de0bd6] test
   1 files changed, 1 insertions(+), 0 deletions(-)

On Fri, Aug 26, 2011 at 04:12:33PM -0500, Shaun Ruffell wrote:

My filesystem (HFS+ on OSX Lion) is case-insensitive, yeah. I bet you're right, because in one repo the modified file shows up in `git status` as LOG.txt but in the output from `ls` it is called `Log.txt`. It's the same in the other repo that has the problem, the case of the filename that is having the problem is different in `git status` and `ls`.

Perhaps the problem might have been introduced by moving the repo from a case-sensitive to an insensitive filesystem? Or by originally starting the repo on a sensitive fs and then using git clone to clone it onto an insensitive one. Or, maybe at some point I committed a change to the case of the filename and that introduced a problem on case-insenstive filesystems.

Did you find a way around the problem? I guess that the repo does not really have any uncommitted changes, so I just want to convince `git status` and `git diff` of this.

On Sat, Aug 27, 2011 at 05:35:36PM +0200, seanh wrote:

I think I fixed it like this:

  git config core.ignorecase false

then backup the LOG.txt file and:

  git rm Text/Log.txt
  git rm Text/LOG.txt
  git commit

then copy the LOG.txt file back again and add and commit it. Seems to be okay now.