![]() ![]() Note the colon in that filename: turns out GNU patch on windows (at least v2.7.6) uses a Unicode homoglyph to simulate a colon in a filename. Patching file Writing-Bops:-The-Bebop-Schema-Language.md This should list one or more files being patched as a result, e.g. If you forget -R, patch will ask (answer es) if you do specify -R patch will yak even more, so -f ( force) is in order to shut up patch and just do the job. Now that you have a patchfile, you can apply it to the current working directory: it must be applied in reverse ( -R): patch -R -f -i p.patch # ^^^^ reference the git hash with the offending original file(s) If you have multiple files with colons or other trouble, all the missing content will be listed in the patchfile: one patchfile to catch it all! git diff ec28c8ddd5f8c83d11604bcae69afb46d79b1029 > p.patch Use this next command to get a patch file with all the missing changes. (BTW: TortoiseGit would hang forever if you tried to diff/compare these commits!) Turns out we can get the missing content after we did git config core.protectNTFS falseīy running patch. Of course, we wanted to fix this in place, without going the extra 'sparse clone' or WSL mile.) ( In our case, we were messing about with a github wiki clone and ran into this issue of filenames containing colons. You're running Windows, using NTFS storage, git-for-windows with bash as your shell and have a patch.exe available ( patch -version should report something like "GNU patch 2.7.6").when you are tracking a third-party git repo. Ditto on git apply-filter and other techniques to 'permanently rewrite' git history, f.e.This assumes you cannot or will not use a sparse clone for some reason.To fix this, we need to get a copy of the original offending file(s)' content another way, so we can restore it. ![]() ![]() Writing-Bops:-The-Bebop-Schema-Language.md (~9KB) -> Writing-Bops (0 KB) However, git now will produce filenames clipped to the colon and with zero content.Į.g. Turns out git config core.protectNTFS false does work, insofar as to not produce fatal errors on git checkout anymore. Regrettably, git config core.protectNTFS false turned out not to be enough the contents of the colon-carrying filenames are lost (filesize = 0). Is there any other possibilities?Īddendum - git version 2.34.1.windows.1 & others(?) Why isn't sparse-checkout working on Windows. !/configs/perlbrew/perls/perl-5.24.1/man/man3Ĭheckout works fine on Linux, MacOS and WSL, only problem is that my IDEs don't work there. I have also tried both types of line endings and using various version of. This was done with Git for Windows "git version 2.28.0.windows.1". Remote: Compressing objects: 100% (49/49), done. I've tried this with no effect as evidenced in the following: Unfortunately, this is is a team resource and can not be fixed in the foreseeable future.Ģ) Use sparse-checkout. I suspect the issue is that the path contains a : which is illegal on Windows.Īfter researching the error, I've found 2 possible answers:ġ) Change the path on the repository file. This sends your branch up to GitHub.When I attempt to checkout a repository from github I get the error: error: invalid path 'configs/perl-modules/DIST.64/perl-HTML-Tree-1:5.'
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |