Cloning Linux kernel code under Windows

[mfide]

I use git version 2.37.1.windows.1 on my Windows 10 Pro 64 bit machine with a NTFS partition.
I want to clone some Linux kernel code from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

git.exe clone --progress --recursive -v "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git" "C:\_Projects\linux-stable"
Cloning into 'C:\_Projects\linux-stable'...
Looking up git.kernel.org ... done.
Connecting to git.kernel.org (port 9418) ... 145.40.68.75 done.
remote: Enumerating objects: 327, done.
remote: Counting objects: 100% (327/327), done.
remote: Compressing objects: 100% (184/184), done.
remote: Total 10739706 (delta 182), reused 203 (delta 143), pack-reused 10739379
Receiving objects: 100% (10739706/10739706), 4.12 GiB | 22.28 MiB/s, done.
Resolving deltas: 100% (8585326/8585326), done.
Checking objects: 100% (33554432/33554432), done.
error: invalid path 'drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

git did not exit cleanly (exit code 128) (768672 ms @ 30/08/2022 11:08:03)

Then I added following lines in to .git/config and try to checkout to master again:

[core]
    longpaths = true
    sparsecheckout = true
    protectNTFS = false

and then get following errors:

git.exe checkout -f master --
error: unable to create file drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c: No such file or directory
error: unable to create file drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h: No such file or directory
error: unable to create file include/soc/arc/aux.h: No such file or directory
Your branch is up to date with 'origin/master'.
Already on 'master'


git did not exit cleanly (exit code 1) (157640 ms @ 30/08/2022 11:13:47)

I know that aux is one of reserved word in Windows file system, but I wonder if git can manage the file names which are reserved automatically in a similar way they do with CR and LF? (for example it can replace the file name during cloning and committing)

[dscho]

Related: #2803.

The broader problem is not actually specific to Windows because it will require a change in core Git if we want to allow checking out files under a different name than they were recorded.

Although that might not go over well: If you clone a repository such as the Linux kernel's, there is more than just Git that assumes that the file names are on disk as they were committed, e.g. the build system.

In any case, you probably will want to start a discussion on the Git mailing list (send plain-text messages, HTML messages are dropped silently).

[mfide]

But interestingly on my win11 desktop, right click -> New -> Text Document and replacing the file name as aux.c or aux.h works fine. More than that, I can edit the file with Notepad++ and save back without any restrictions. (Windows 11 Version 10.0.22000.918) But git clone on Win11 still gives the same error that I get on Windows 10 mentioned above.

I didn't get what is the issue with git then.

[dscho]

But interestingly on my win11 desktop, right click -> New -> Text Document and replacing the file name as aux.c or aux.h works fine.

"Works on my machine" is not really adequate if you run a project that's used by millions of users.

[mfide]

"Works on my machine" is not really adequate if you run a project that's used by millions of users.

You are right, I confirmed that on some other Win11 machines as well, obviously Microsoft had some improvement on the topic since Win10, but I couldn't find official statement for it. On the other side, case sensitive files and folders were already supported through a special flag which can be set for a folder via fsutil. I believed that with all those updates, windows file system is fully compatible with Linux Kernel Source code. I will do the further tests and post the results here.

[Okeanos]

You just ran into some of the magic that is the Windows file naming convention. Specifically:

Do not use the following reserved names for the name of a file:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended.

As far as I understand it these are reserved names and simply cannot be used as actual file names on Windows. They have a special meaning (backwards compatibility FTW) and will not (ever?) behave the way you want them to, i.e. as actual files.

Specifically, Microsoft even says that simply appending a file extension won't save you from weird behaviour (as also apparent by your example) – so a CRLF-rewrite like feature would have to do something way, way different to keep track of that conversion.

[dasa]

I've run into a similar issue with cloning a repo that has a branch named x/con:

error: cannot lock ref 'refs/remotes/origin/x/con': Unable to create 'C:/Users/jenkins/.jenkins/workspace/online/.git/refs/remotes/origin/x/con.lock': Invalid argument

Would it be possible for git to avoid this?

[dscho]

Would it be possible for git to avoid this?

Not at this time. Git initially stores all refs as "loose refs", i.e. as files in the file system, where the path is relative to the Git directory.