Hi Johannes, Indeed there are two -- one lives under the MSYS2 prefix, the other under Program Files. However, Cargo seems to access the Git data directly, so I believe you're right -- it's not able to understand the path syntax. As for MSYS2, so far my testing points to an inability to chain back to the original clone. Given the mixup of installs, it's best to focus on fixing that. Thanks for the explanation! amyspark On 12/04/2024 13:16, Johannes Sixt wrote: > Am 12.04.24 um 15:05 schrieb L. E. Segovia: >> Under a MSYS2 shell, follow these steps (feel free to replace the choice >> of remote repo with any other supporting a Rust crate): >> >> 1. `cd` to a directory of your choice (let's call it `dirA`). >> 2. `git clone https://gitlab.gnome.org/GNOME/librsvg.git .` >> 3. `git checkout -b cerbero_build`. >> 4. `cd ..` >> 5. `git clone <full path to dirA> -s -b cerbero_build dirB` >> 6. `cd dirB` >> 7. `git status` >> >> Now switch to any other shell of your choice, such as Git Bash, CMD, or >> PowerShell, and try issuing commands such as `git status`. It will >> result in a wall of "error: unable to normalize..." > > Thanks, that is much more helpful. Here are my assumption, my > explanation of the symptoms, and the conclusion (which is basically "if > it hurts, don't do it"): > > I assume that you have two installations of Git. One installation is > used when you use the git command from the MSYS2 shell; it is the MSYS2 > version. The other installation is Git for Windows or equivalent that is > used by all the other shells. > > When you clone a repository with -s, a .git/objects/info/alternates file > is initialized that contains the path to the original repository. You > can see its contents with `git count-objects -v`. I tested the > reproduction recipe with my own build (which is a MinGW build, much like > Git for Windows), and it looks like this: > > C:\Temp\repoclone>git count-objects -v > count: 0 > size: 0 > in-pack: 0 > packs: 0 > size-pack: 0 > prune-packable: 0 > garbage: 0 > size-garbage: 0 > alternate: C:/Temp/repoorig/.git/objects > > See the last line? It begins with a drive letter. When you call the > command with the MSYS2 version, it will look more like this: > > alternate: /c/Temp/repoorig/.git/objects > > This is the MSYS2/Cygwin absolute path with a "drive letter". > Unfortunately, this kind of path is unintelligible for Git for Windows. > It expects absolute paths to begin with drive letter-colon or a > double-slash or double-backslash. For this reason, it reports "unable to > normalize alternate object path". > > The conclusion is: Do not use two different flavors of Git on a > repository that is set up with a link to an alternate repository. > > BTW, I did not do the followup test with `git am`. (Actually, I did, but > there were no errors.) So, I cannot tell why your MSYS2 version suddenly > also reports the "unable to normalize" error. > > -- Hannes > -- amyspark 🌸 https://www.amyspark.me
