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
directory)
deleted: explorer/data/plugins/mq.serial/queues/channel-nodes:0
deleted:
explorer/data/plugins/mq.serial/queues/channel-nodes:ajxp_conf
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 [1] and [2] in general for more info.
Untracked files:
(use git add file... to include in what will be committed)
explorer/data/plugins/mq.serial/queues/C81O4T~E
explorer/data/plugins/mq.serial/queues/CBTQK4~4
These, I reckon, are just 8dot3 filenames automatically created by
NTFS for those two invalid filenames containing the ':' characters.
See [3] 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.
1. http://stackoverflow.com/a/5788054/720999
2. http://stackoverflow.com/search?q=[git]+modified+windows
3. http://blogs.msdn.com/b/adioltean/archive/2005/01/27/362105.aspx
--
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
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
