On 2025-01-04 at 14:21:46, Youtian WANG wrote: > In a commit of a public repo (which might still require a sign in using github account, etc, due to possibly the service maintainer's configuration): > > https://gitee.com/whyyouteach/erg4eye/commit/f5e2c1ea25aaee24868a1790cf59ccd0a8288c3c > > , a file of full absolute path (including the volume, also known as drive letter, in windows operating system) shows up: > > C:\erg4eye_3\xiangxun23080202 > > ; I'm not sure how that path gets into the repo, as this is a repo for a pack of students. Maybe it's due to a 3rd party tool, or a direct upload via the web page of the git service. I noticed that in: > > https://github.com/gitkraken/vscode-gitlens/issues/932 > > , some similar issues appeared involving a vsCode extension for git. > > I cannot checkout outWith the above described commit; the error message is: > > error: invalid path 'C:\erg4eye_3\xiangxun23080202' > > ; > > My question is: > 1) Per git design, such full absolute is not allowed as it might be out of repo, right? This is not a full absolute path as Git stores it. Git uses the standard Unix slash character, and only that character, as the path separator internally, unless you're on Windows. So this is a single file in the top-level of the repository called `C:\erg4eye_3\xiangxun23080202`. I'm on Linux, and I did this to test, and it works just fine: ---- $ git init test-repo Initialized empty Git repository in /tmp/user/1000/test-repo/.git/ $ cd test-repo $ touch 'C:\erg4eye_3\xiangxun23080202' $ git add C:\\erg4eye_3\\xiangxun23080202 $ git commit -m + [dev (root-commit) 0d1da07] + 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 "C:\\erg4eye_3\\xiangxun23080202" ---- Now, this clearly won't work on Windows, as you pointed out, but nor will a file called `aux.h`, and we wouldn't want to exclude that from working (Linux contains such a file, for instance). Windows contains a variety of filenames that are unacceptable for various reasons and users not using Windows shouldn't be negatively affected because of its less capable handling of filenames. I assume you're on Windows, so you could try using WSL to verify that it works just fine on Linux, provided you do it on a native Linux volume (and not on a Windows one). > 2) If it's done by a 3rd party tool which might be buggy, git.exe or the git server would bury the problem in the repo history as long as it's not checked out. As a git hosting service wouldnot bother to check it out, hence it will not be an issue with the server. But once it's cloned and that commit is checked out, an issue would emerge. Is this understanding correct? Again, I don't think "buggy" is the right word, but it will remain hidden until you attempt to check it out _on a Windows system_. Some hosting platforms contain checks for paths that are problematic on various OSes, such as pairs of files that differ only in case, so it may be caught on push to such a platform as well. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
