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.

Reply via email to