On Wed, 2020-06-03 at 14:34 UTC, Paul Smith wrote: >I'm not super-familiar with the Git build system so maybe there are >mitigations for this there but: GNU make always treats whitespace as a >word separator so it will apply the "dir" function to each word. So: > >>$(dir C:/Program Files/Git/mingw64/libexec/git-core) > >is equivalent to writing: > >>$(dir C:/Program) $(dir Files/Git/mingw64/libexec/git-core) > >and the expected result is: > >>C:/ Files/Git/mingw64/libexec Yeah, I figured that was the case after skimming over GNU make reference sites online and reading as much. Still, I figured I'd ask in case Git or Git Bash specifically had been built to account for this in Git for Windows, or if anything had changed since the documentation I'd read had been written. >No. Make in general, and GNU make in particular, doesn't expect to be >given paths with whitespace in them. > >Again I'm not an expert in the Git build system but my understanding is >that the install can be relocatable: in that case I recommend you build >it into a location where there is no whitespace in the path, then move >it wherever you like after building. Ideally, yes. However, Git-Gui's Makefile was not written with this in mind. It will append directories to DEST during installation that can (and do) include drive letters. Again, the file can be modified to fix this on a case by case basis, but ideally I wanted to learn if this was all already known about this particular Makefile and if it was expected behavior. I've actually already modified my copy of Git-Gui's Makefile to account for whitespaces since I first wrote about it to the mailing list, but since I suspect that it was automatically generated by software, I'd rather learn if the tool responsible is open source and could be modified to account for spaces in directory and file names instead of manually fixing up every automated Makefile for each repository Windows users come across until the tool is changed or no longer in use. If I were to share it, should the patch by submit to a new e-mail thread, or would it be fine to send it in as a reply to this one using the --in-reply-to argument in git? Thanks in advance for your time.
