git apply on Windows doesn't work right now for files that SVN checks
out as CRLF. There is no way to force SVN to check everything out with
Unix line endings on Windows. Files with svn:eol-style=native will
always come out with CRLF, breaking git apply, which wants Unix line
endings. My workaround is to list all files with this property set in
the change, and run dos2unix on them. SVN doesn't commit a mass
reformatting, it knows the file is a text file because of the
svn:eol-style property.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I committed rL301245 with this modified script, which touches files with and without svn:eol-style=native.
There are certain files in the repo that absolutely must be CRLF, and are documented as such. So this patch would break those files. I'm not sure if that's a problem though. Can we just wash our hands of this added complexity and globally remove this property? We've been doing it on a file-by-file basis for months, and nobody has noticed or complained
Well that's exciting.
I don't have a position on what Zach is suggesting, but as far as the change to the script goes, I'm happy with it.
llvm/utils/git-svn/git-llvm | ||
---|---|---|
92 ↗ | (On Diff #96465) | Do we need to close this at some point? |
195 ↗ | (On Diff #96465) | Would prefer to call some os.path function if there's one that DTRT for this, but if not, whatever. |
202 ↗ | (On Diff #96465) | Nit, probably want something to guard against the case where the filename contains ' - '. Probably rsplit(' - ', 1)? |
It won't, because those files will not set svn:eol-style to native. The ones I know of in the clangd test directory explicitly set svn:eol-style to CRLF, or don't set it at all.
Can we just wash our hands of this added complexity and globally remove this property? We've been doing it on a file-by-file basis for months, and nobody has noticed or complained
I'd rather do this, and hope it works well enough that we can survive until the git migration.
llvm/utils/git-svn/git-llvm | ||
---|---|---|
92 ↗ | (On Diff #96465) | We could, but what do you think about opening it once in a global and never closing it? |
195 ↗ | (On Diff #96465) | git seems to use forward slashes in its output on Windows, so I hope this is safe. I could probably do f.split('\\/', 1)[1], or try to combine os.path.sep and os.path.altsep, but that doesn't seem better. |
202 ↗ | (On Diff #96465) | Done. I created such a file, added it to svn, gave it a property, listed it, and rsplit does the right thing. |
llvm/utils/git-svn/git-llvm | ||
---|---|---|
195 ↗ | (On Diff #96465) | Ah, I remember now, I have fought with this before. Path munging is done by msys. Really horrible. But if your Python is not aware of it, then pathsep doesn't work, and...yeah. If this works, is probably good enough for now. |