bug: git filter-branch command fails with asdf-related Python error?
cobyism opened this issue · 5 comments
Describe the Bug
Just now I ran a git filter-branch
command to remove a file from my repository history, which resulted in output containing an error related to asdf, python, miniconda—none of which have anything to do with the current repo/directory (this is a ruby/node static site repo that doesn't make use of or miniconda nor python at all as far as I'm aware).
Here's the output:
$ git filter-branch --index-filter 'rm -f /path/to/file.ext' HEAD
WARNING: git-filter-branch has a glut of gotchas generating mangled history
rewrites. Hit Ctrl-C before proceeding to abort, then use an
alternative filtering tool such as 'git filter-repo'
(https://github.com/newren/git-filter-repo/) instead. See the
filter-branch manual page for more details; to squelch this warning,
set FILTER_BRANCH_SQUELCH_WARNING=1.
Proceeding with filter-branch...
No preset version installed for command gettext.sh
Please install a version by running one of the following:
asdf install python 3.11.2
or add one of the following versions in your config file at /Users/cobyism/.tool-versions
python miniconda3-latest
Not only that, but (separately from this project) I already have this version of python installed as far as asdf
is concerned:
$ asdf current python
python 3.11.2 /Users/cobyism/.tool-versions
Steps to Reproduce
cd
into git repo, which doesn't make use of python at all.- run a
git filter-branch
command as detailed above. - observe output errors relating to python and miniconda installations (which are installed via
asdf
already.
Expected Behaviour
Running a git command should result in no output related to asdf, python, or miniconda—even if the git command runs into an error. I would expect these systems/toolchains to be completely independent of each other.
Actual Behaviour
There has clearly some interdependencies created between git, asdf, python, and miniconda, even for git commands and repos which have nothing to do with python or miniconda.
Environment
OS:
Darwin [REDACTED] 23.0.0 Darwin Kernel Version 23.0.0: Tue Jun 13 21:17:44 PDT 2023; root:xnu-10002.0.116.505.3~3/RELEASE_ARM64_T8112 arm64
SHELL:
zsh 5.9 (x86_64-apple-darwin23.0)
ASDF VERSION:
v0.11.3
ASDF ENVIRONMENT VARIABLES:
ASDF_DIR=/opt/homebrew/opt/asdf/libexec
ASDF INSTALLED PLUGINS:
clojure https://github.com/asdf-community/asdf-clojure.git master 490074c
golang https://github.com/kennyp/asdf-golang.git master 21d9c32
haskell https://github.com/asdf-community/asdf-haskell.git master 6b66231
nodejs https://github.com/asdf-vm/asdf-nodejs.git master 4f8aa3d
python https://github.com/danhper/asdf-python.git master 8505457
ruby https://github.com/asdf-vm/asdf-ruby.git master 5e2eded
asdf plugins affected (if relevant)
python
Does the fix mentioned there address your issue? I think it was mentioned that this could be an issue with the plugin (e.g. asdf-python) and not asdf itself.
@hyperupcall Do you mean the suggestion in #693 about altering the shim to modify the $PATH
order? or the resolution to asdf-community/asdf-python#44 being to uninstall python/anaconda etc?
I haven’t tried either, but even if manually tweaking the shim were to resolve this specific instance, it still seems pretty unfortunate that a command that is already installed and working on the system is hijacked by an asdf shim in a way that breaks. Uninstalling the python plugin etc. also doesn’t feel like it should really be the answer either.
Since I’ve also just run into a thematically similar issue with asdf hijacking my homebrew-installed ffmpeg
command, the observation I’d make is that the common trait seems to be asdf shims inserting themselves into non-plugin-related commands.
I meant the fix involving changing the $PATH
order. I agree that it is unfortunate that asdf
seemingly overrides another command, and the $PATH
order fix is only a temporary one.
It seems these issues are popping up more frequently, and it's something I want to investigate, but only after my other PRs to this repo are merged.
Gotcha 👍. And yeah as a temporary fix I can work around the $PATH issue no problem.