On Sun, 5 Apr 2015 15:21:36 -0700 (PDT)
Andres Suarez <webmas...@colservers.com> wrote:
> Hi, I have a git repository. This repository is under a Linux
> machine. I also have this repository available on a Windows machine
> under a network drive. I have git installed both on windows and Linux.
> nothing to commit (working directory clean)
> When I do git status under Windows using cdm on the network folder I
> get: ***********
What is "cdm"?
> Changes not staged for commit:
> (use "git add/rm <file>..." to update what will be committed)
> (use "git checkout -- <file>..." to discard changes in working
> deleted: explorer/data/plugins/mq.serial/queues/channel-nodes:0
The ':' is not a valid character for Windows pathnames -- it can only
appear once in a pathname -- exactly at position 2 in it (if we count
from one), with the first one being a drive letter.
IOW, this pathname has no chance of being correctly manipulated by Git
for Windows running on Windows machine.
> modified: framework/cli/views/webapp/protected/yiic
> modified: framework/db/schema/cubrid/CCubridColumnSchema.php
I can only guess here, but it might have something to do with
end-of-line conversion settings.
Does the project include the .gitattributes file?
See  and  in general for more info.
> Untracked files:
> (use "git add <file>..." to include in what will be committed)
These, I reckon, are just "8dot3" filenames automatically created by
NTFS for those two invalid filenames containing the ':' characters.
See  for more.
While technically these names (supposedly) refer to the contents of
those files with invalid names, Git's index has no way to know about
this and hence shows these files as untracked. [*]
> Why this is different? I try deleting the repo and cloning again,
> clean the cache, but always, when doing under Windows I say the same
> status, and when doing under Linux I saw directory clean.
As you can see from the symptoms, the problem has nothing to do with
transfer of Git repository (the "fetch" part of cloning), and the
problem is rather in the work tree (the "checking out" part of cloning
-- which creates files as recorded in the index in the work tree).
[*] It's interesting to bring this problem up with the Git for Windows
developers: I wonder if it's possible to somehow inspect the
metadata of a file on NTFS to know its "true" name and use that to
search it in the index.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.