Pass -z arg to git ls-files & split on null char
#2634
Conversation
|
The specs all still pass, but I'm at a loss for where to put a test for this functionality (no such test exists or I'd modify it). I've been making this small change to the gemspec generated by Bundler for my own projects, so I figure I'd safe my future self some time and open a pull request. If a more frequent committer could figure out where best to put the new test I'll add one. |
|
Does |
|
Gah. I guess my build failed. Lemme fix and rewrite this commit. Getting a coworker to try this out on Windows, will get back with the verdict. I don't see any documentation to the contrary. |
|
Worked fine for my coworker. I've got a copy-paste error in my commit (these specs take forever so yeah I was lazy. That's what Travis is for, right?) and will fix it today. |
It seems a little bit paranoid to assume there might be a newline or tab in a file name, but it's perfectly valid on many systems. When such a character exists in a filename, `git ls-files` will return something like `"file\nname"` in its listing, which is problematic because the calling code expects neither the escaped whitespace nor the quotes. By passing the `-z` argument, git uses the null character as the sep- arator, never escaping whitespace nor quoting file names. Additionally, I found I had to use the "\x0" syntax to represent the null character because "\0" is ambiguous in the context of for instance `String#sub`.
|
I don't know why my commit didn't get annotated by Travis (maybe because I rebased and |
|
This seems legit. Thanks! 👍 |
Pass `-z` arg to git ls-files & split on null char
|
Looks like this made it into bundle 1.3 stable but never master? |
|
We need to merge up from 1-3-stable to 1-5-stable and master, and up from master to 2-0-dev. Hopefully I can pull that off in the next few days. |
It seems a little bit paranoid to assume there might be a newline or tab in a file name, but it's perfectly valid on many systems. When such a character exists in a filename,
git ls-fileswill return something like"file\nname"in its listing, which is problematic because the calling code expects neither the escaped whitespace nor the quotes.By passing the
-zargument, git uses the null character as the separator, never escaping whitespace nor quoting file names.