Yves Goergen <nospam.list@xxxxxxxxxxxxxxx> writes:
> 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
--
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