Re: Bug? Git checkout fails with a wrong error message

From: Thomas Rast <trast@student.ethz.ch>
Date: Jan 16, 2012, 19:17 UTC
Message-ID: <87r4yzzcci.fsf@thomas.inf.ethz.ch>
In-Reply-To: <4F14718B.80209@unclassified.de>

Yves Goergen <nospam.list@unclassified.de> writes:

Show 5 quoted lines

> It's getting more weird. I believe that (msys)Git doesn't really know
> how the filesystem on its operating system works. I have made some more
> changes now and want to commit them. TortoiseGit reports the files
> Form1.Designer.cs and Form1.designer.cs (note the case difference) as
> modified and ready to commit. How is that supposed to work?

Depends.

If you work together with developers who have a case-sensitive FS (such as Linux, or with the right options OS X), it's entirely possible that this file exists in both spellings within the repository.

Otherwise, because Git needs to have the ability to store such spellings, there are some ways of introducing them (e.g., git-update-index).

I suspect the adoption rate of TortoiseGit across this list is about 0%, partly because it is a Windows-only tool, partly because it was written almost entirely without interacting with the Git list. So speaking in TortoiseGit terms here will most likely get you nowhere.

> If the index is such a problem child, how can I safely delete it
> completely and maybe have it regenerated if Git can't live without it?

The index is not only, as its name might imply, a throw-away cache. It is also used as the area where you prepare the contents of the next commit, and thus might hold data you do not want to lose. Nevertheless, you can discard and reset it to the contents of HEAD with

  rm -f .git/index
  git reset

> Great, I have the same file with an equal name twice in my repository
> (with 'git ls-files').
> 
> How stupid! Git, go learn file names.

Please cut&paste (!) actual command invocations (!) and outputs.

To see why this is important, consider

  "I have the same file with an equal name twice in my repository"

Judging by how this thread is going, there are at least four ways this could be interpreted:

* You have the byte-for-byte identical file name listed twice in the
  index.  That would be a pretty bad bug.

* Ditto, but in a commit.

* You have two filenames in the index that differ only by case, which
  makes them identical to your OS.

* Ditto, but in a commit.

See what I mean?

So please, let's be precise. You could start by cut&pasting the outputs of the following commands:

  git ls-tree -r HEAD
  git ls-files --debug
  git status -s

Otherwise, you can keep throwing around fuzzy complaints all you want but nobody will be able to help you because we cannot determine the exact state that your repository is in.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch