- #Directory list and print pro 2.35 update
- #Directory list and print pro 2.35 Patch
- #Directory list and print pro 2.35 portable
- #Directory list and print pro 2.35 Pc
The issue was the portable Git installation of Visual Studio, which had the version 2.35.2. Git config -global -add safe.directory '%(prefix)///MyNas/User/Repo' To add an exception for this directory, call: When opening the repository in Visual Studio, this error showed up in the console: Opening Repository:įatal: unsafe repository ('//MyNas/User/Repo' is owned by someone else)
#Directory list and print pro 2.35 Pc
Since my NAS and PC are not in the same domain, I cannot set my PC user as the owner of the NAS directory. My IDE: Visual Studio 2022 Enterprise 17.2.0 Preview 4.0 (latest).My NAS and PC are not in the same domain.The remote branch was cloned into a directory on X:\.Mounted SMB network share from my NAS \\MyNas\User as X:\.Git config -global -add safe.directory "*" However, if you are the sole user of your machine 100% of the time, and your repositories are stored locally, then disabling this check should, theoretically, pose no increased risk.Īlso note that you can't currently combine this with a file path, as the command doesn't interpret the wildcard * as an operator per say– it just takes the "*" argument to mean "disable safe repository checks/ consider all repositories as safe".ġ - If this fails in your particular terminal program in Windows, try surrounding the wildcard with double quotes instead of single (Via this GitHub issue): You should not do this if your repositories are stored on a shared drive. gitconfig file: īefore disabling, make sure you understand this security measure, and why it exists.
It will add the following setting to your global. Git config -global -add safe.directory '*' 1
#Directory list and print pro 2.35 Patch
Starting in Git v2.35.3, safe directory checks can be disabled, which will end all the "unsafe repository" errors (this will also work in the latest patch versions of 2.30-34). I used a Linux-like directory directory structure here, but the same is true on Windows. The new git version will stop here and print the message we saw in the question.Īdding the directory /home/tommy/rental_space to the safe.directory variable would allow git to proceed but is, as explained, a security risk. Then it will again go up, but rental_space belongs to tommy, not mary. It will go up one directory, check in mary, but again find no. Say mary executed git in /home/tommy/rental_space/mary/projects, then git will check in projects, but find no. This is a security risk, because another user, in this case anyone that can act as tommy, can affect mary's execution of git and possibly cause trouble.įrom Git v2.35.2 and onward, the traversal will stop as soon as the directory entered belongs to a user other than mary. The first it finds is the one from /home/tommy/.git. If mary, by mistake, where to execute git in her directory, but outside of her phone_app project, then old git would go up the directory tree to search a. In this case, the user tommy owns his own directory under /home, but (for some reason) rents out space to other users, in this case mary and anthony. Lets look at the following simple directory structure. Going through the post about the vulnerability again after a good night's sleep, I think a bit of clarification is in order. Running git config -global -add safe.directory /opt/flutter did indeed fix the problem for me. I am not working as root, thus I run into the same problem. I ran into the same problem using flutter on Linux, which on my distro was installed in /opt/flutter. git folder (the git repository) is the issue.Ĭloning the project anew is a platform independent way to make sure you are the owner.
#Directory list and print pro 2.35 update
The update is only a few hours old, so I guess things are still in flux.įor now, as the message from git suggests, execute git config -global -add safe.directory F:/GitHub/my-projectĪnd make sure you are calling git from within F:/GitHub/my-project for now.ĮDIT: As we found out in the comments below, the owner of the parent of the directory containing the. Is the user you're currently logged in with also the owner of the folder?Īlso, are you invoking git from within the repository directory?
I think it has less to do with your email, and more with the owner of the directories on your filesystem. This seems to be related to this announcement of a vulnerability:
0 kommentar(er)
