git-subtree installation is broken #3260
Comments
devhawk
changed the title
|
Note, winget is installing 2.31.1, where subtree appears to work. when I installed the non-portable version of 2.32.0, git subtree was still broken. |
|
Could you maybe bisect through the snapshots (both v2.32.0 and v2.31.1 are in there)? I would love to assist, but I am somewhat worn out by a lengthy bug hunt today. |
That's interesting. That's probably supposed to say something more like
Did we change something about how we call dashed externals? Specifically regarding working directory? |
|
If that were the case, other dashed command should be affected, too (e.g. I vaguely remember that @avar played in |
|
I think the person who did most things in contrib/subtree between 2.31 and 2.32 was @LukeShu, though. Including the commit that introduced our error message |
|
And it seems to be the test "${PATH#"${GIT_EXEC_PATH}:"}" = "$PATH"in line 8 of |
|
That commit message says
yet it errors out, if that is actually the case. I think that |
|
I'll try to check if these issues also appear on linux tomorrow. I think I'll encounter the same issues on arch's official git package. I'll then submit fixes to the appropriate places. |
|
The culprit is 22d5507. And it probably only breaks on Windows, and it breaks hard here. The reason is that it asks The problem is that |
|
Sorry for the noise, I missunderstood both you and the script... |
|
@devhawk could I trouble you to download the installer from https://github.com/git-for-windows/git/actions/runs/922160854 to verify that the fix I provided in #3264 works for you? |
No worries at all, your help was invaluable. I would not have been able to investigate, and the fix would not have come around this quickly. |
I downloaded the portable version and was able to run git subtree on my windows box without issue. Thanks @dscho! |
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's keep the original spirit, and hack together something that unbreaks the logic on Windows. A more thorough fix would look at the inode of `$GIT_EXEC_PATH` and of the first component of `$PATH`, to make sure that they are identical, but that is even trickier to do in a portable way. This fixes git-for-windows#3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Indeed! The error message is borked because when it's deciding what to print it assumes that the directory separator is forward-slash |
I'm using |
Yes, that comment was based on my poor understanding of the issue. |
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's keep the original spirit, and hack together something that unbreaks the logic on Windows. A more thorough fix would look at the inode of `$GIT_EXEC_PATH` and of the first component of `$PATH`, to make sure that they are identical, but that is even trickier to do in a portable way. This fixes git-for-windows#3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes git-for-windows#3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes git-for-windows#3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
FYI for those encountering the git-subtree installation is broken issue and landing here via google after getting this error message: It looks like either your git installation or your git-subtree installation is broken.It appears the git subtree installation is broken issue is with Git for Windows. I was able to download an older version from: https://github.com/git-for-windows/git/releases/download/v2.31.0.windows.1/Git-2.31.0-64-bit.exe This fixed the issue for me while we await a fix. |
|
@CaseGuide please avoid suggesting to downgrade when we worked so hard on a fix. Point people to the installer artifact of https://github.com/git-for-windows/git/actions/runs/922160854 instead. That's much, much better advice. |
|
@dscho I just got hit by this in a weird spot where I basically have to stop work. This was fixed two weeks ago, about four days after the previous release; maybe the artifacts are great but it's not clear what those will do to the normal update process in git-for-windows. How long until a new release appears either on the releases page or in edit: downloaded the installer artifact provided above, unpack/installed and it worked fine to get me going. It was a little arcane for me, not being familiar with the GitHub process and I certainly would never have found it without a link. |
|
Edit: The .zip file worked when I tried downloading it again. |
The fix is still under discussion on the Git mailing list: gitgitgadget#978. It has not even been accepted into Git's
The upgrade process should be the exact same. No downgrades should be suggested, but once a new version is available, it should be offered for installation.
Yes, I saw that from time to time that downloads "succeeded" even if they were incomplete. I think it is an Amazon S3 issue, but I can't know for certain. |
The `git subtree` command was [completely broken in the previous release](git-for-windows/git#3260), and was fixed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
Hi, Thanks for the fix, yet I tried to install it but I still have the issue. |
That's quite an odd commit. And I don't think it has this fix. |
Indeed. It looks like this Git version was indeed built from a revision that does not have the fix: 262eaa2...5f2d943 (the fix is in 5f2d943). |
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes #3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes #3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes #3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes #3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes #3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 22d5507 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes git-for-windows#3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Setup
defaults?
to the issue you're seeing?
Only seems to happen with Portable git. invoking subtree when git is installed via winget on this machine works fine
Details
git-cmd
Minimal, Complete, and Verifiable example
this will help us understand the issue.
help content of git subtree command
URL to that repository to help us with testing?
n/a
The text was updated successfully, but these errors were encountered: