-1

Hey guys I've looked all over stack overflow and have tried a lot of things. My git commands won't work when there is spaces in the file paths (windows). Here is an example of what I am trying to checkout enter image description here

As you can see I can't checkout any of them because of that space in the file path after legacy.vI've tried putting the file path in "" and that doesn't work. Any suggestions?

git checkout stories/nucleus/"legacy "/tag/add-tag.stories.js
fatal: cannot create directory at 'stories/nucleus/legacy /tag': No such file or directory

git checkout "stories/nucleus/"legacy /"tag/add-tag.stories.js"
fatal: Invalid path '/tag': No such file or directory

I've also tried putting %20 in between the spaces like some other forums have recommended.

Mureinik
  • 297,002
  • 52
  • 306
  • 350
  • `I can't checkout any of them because of that space in the file path after legacy.I've tried putting the file path in "" and that doesn't work.` Please __show__ what have you tried. Please do not post images of text - post the text as text instead. – KamilCuk Jun 25 '21 at 15:00
  • https://stackoverflow.com/questions/19742256/path-doesnt-work-with-20-for-space-in-filename-in-git-console – Sudz Jun 25 '21 at 15:04
  • 3
    IIRC some filesystems don't support filenames that end with space – o11c Jun 25 '21 at 15:06
  • What's your operating system? – joanis Jun 25 '21 at 19:10
  • I just tested adding a file called `a/b /c/file` on Windows (using Git Bash) and Linux: it worked on Linux, but in Git Bash it tells me `warning: could not open directory 'a/b /': No such file or directory` even though the file system let me create the file and the `git add` did not output any error messages. So, Git Bash bug? – joanis Jun 25 '21 at 19:15

2 Answers2

1

Update

While test tests in my original answer work as I describe, they miss the main point, raised by several different people: Windows does not allow filenames that end with spaces. It's not a bug in Git that it won't create or manipulate such files, it's an OS limitation. And arguably, it's a bug in Git Bash and Cygwin Bash (both are based on the MSYS2 runtime so, really, a bug in the MSYS2 runtime) that they even let me create such files in the first place.

Original answer

I believe this is a bug in Git for Windows. I have created a similar situation and gotten a similar error.

In Git Bash and on Linux:

mkdir -p "a/b /c"
touch "a/b /c/file"
git add "a/b /c/file"
git status

On Linux, git status now tells me I've added that file.

On Windows, git status gives me this warning message:

warning: could not open directory 'a/b /': No such file or directory
On branch foo.conflict
nothing to commit, working tree clean

However, `ls "a/b /c/file" confirms that the file exists on the file system. Attempting to commit also fails.

So, bad news, you might not be able to checkout this file at all on Windows, although maybe a different client could manage it? This might be worth reporting as a bug to Git for Windows.

EDIT: if I use Cygwin and its version of Git, the operations work correctly and I can add and commit the file, but then if I come back to Git Bash I get errors about that file all the time. So this is definitely a Git Bash bug.

EDIT 2: on Git Bash, adding "a/b b/c/file" works without errors, so it's really the space at the end of the directory name that causes the issue.

joanis
  • 10,635
  • 14
  • 30
  • 40
  • Paranoia speaking: just to be sure it's not stripping blanks from the end, say `find a -name file`, does the path still show up as `a/b /c/file` or is it `a/b/c/file`? – jthill Jun 25 '21 at 20:03
  • @jthill good question but no luck: find reports `a/b /c/file` as expected. – joanis Jun 25 '21 at 20:05
  • It's not exactly a Git bug: Windows normally prohibits trailing blanks in file and directory name components. How Cygwin might get around that, I have no idea (well, I have one: it might be using the long-file-name tricks, which might sidestep this). These crazy Windows behaviors are yet another reason to avoid Windows. – torek Jun 25 '21 at 21:11
  • Thanks for that info @torek. Indeed, both Git Bash and Cygwin were able to to create the file and dir with that trailing space, and read them again after, but if I use the File Explorer or the cmd prompt to look at them, they're not working properly. So I'm guessing it's Bash (in Cygwin or Git Bash) that finds a way to create them anyway, but the result is not fully usable by Windows programs either. So agreed, this is not specifically a Git bug, it's a Windows limitation, and maybe a Bash bug for allowing the creation of these files. – joanis Jun 25 '21 at 23:44
0

This is a bug in Windows. Windows does not normally permit trailing spaces in a directory or file name. This isn't a limitation in Git, which can store and handle these paths just fine, but Windows doesn't allow them to be written into the file system.

You have some options about how to address this:

  • Ask the owner of the repository to change the path names.
  • Use the Windows Subsystem for Linux to check this out, and optionally rename the paths so that they don't contain trailing spaces.
  • Use a different operating system.
  • Ask Microsoft to fix the problem.
bk2204
  • 64,793
  • 6
  • 84
  • 100