Please describe the problem.
What steps will reproduce the problem?
What version of git-annex are you using? On what operating system?
Please provide any additional information below.
$> mkdir repo; cd repo; git init; git annex init; git annex upgrade; mkdir -p subdir; cd subdir; touch file; git add file
Initialized empty Git repository in /tmp/repo/.git/
init ok
(recording state in git...)
upgrade (v5 to v6...) ok
git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
error: external filter 'git-annex smudge --clean %f' failed 1
error: external filter 'git-annex smudge --clean %f' failed
$> echo $?; git status
0
git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
error: external filter 'git-annex smudge --clean %f' failed 1
error: external filter 'git-annex smudge --clean %f' failed
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: file
$> git commit -m 'added file'
git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
$> echo $?
1
$> git annex version
git-annex version: 6.20180807+git230-gaa291acfe-1~ndall+1
also happens with 6.20180807-1 but not with 6.20170101-1+deb9u2, so it is a regression
HA -- it is compatibility issue with git somewhere.
I had system wide 1:2.13.0~rc1+next.20170430-1~nd90+1 installation of git, and that was the reason. Similar blows with 1:2.11.0-3+nd1~nd90+1, but works fine with 1:2.19.0~rc2-1 . At least that explains how we did not run into it while testing in DataLad:
But it brings the point of possibly needing to test with a regular debian build of git annex more which would use system-wide git. Also that may be git annex should test git version used and blow with informative message whenever git is too old?
There are a few places in git-annex where it runs git with the cwd overridden, eg to the top of a git repository. If it somehow comes up with a path that doesn't exist, that would explain this error. The most likely one is in
Git.Config.read'
, which git-annex always runs at startup.So it probably comes down to git running the clean filter with the wrong
GIT_DIR
setting or something like that, leading to this as a cascading failure. And I vaguely remember seeing something like that in the git commit log, or having dealt with such a problem before.We could make git-annex upgrade fail to run with too old a git (and it probably should at least when used with a git too old to support smudge/clean filters at all!), but it wouldn't help if the repository was upgraded in a different environment. git is going to run the git-annex via the clean filter before any check can happen and the most git-annex can then do is error out somehow.
See also http://git-annex.branchable.com/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/ which seems to be the same problem without v6; they didn't say what git version.
Ah yes, I was remembering this workaround in git-annex:
Perhaps that broke with some older versions of git. e50ed4ba48f93cf0addb3638a4a9605a10f17976 has the gory details, which includes a git bug.
A good way to debug this is to set:
Then when git runs the clean filter it will display the git environment variables.
Reproduced in a debian stable chroot with current git-annex in it.
Verifies my theory.
Unfortunately git 2.11.0 has the bug that I made git-annex look at
GIT_PREFIX
to avoid.So, it's not as simple as not looking at
GIT_PREFIX
at all with this version of git. WhenGIT_WORK_TREE
is relative, andGIT_PREFIX
is set, it needs to combine them to get the actual path to the work tree.Perhaps git-annex should only use
GIT_PREFIX
for fixup of relativeGIT_WORK_TREE
, but not forGIT_DIR
. I've so far only seen it be needed forGIT_WORK_TREE
; I only made it also be used forGIT_DIR
out of an assumption git would be consistent in its bugginess.Oh hell, here's another way it fails, with git 2.19:
That one does not involve
GIT_DIR
, insteadGIT_WORK_TREE
is not relative toGIT_PREFIX
so the workaround that assumes it is breaks. I guess that we could say thatGIT_DIR
is not relative to some directory in this case, so theGIT_PREFIX
is irrelevant.Kind of feels like git's behavior is so inconsistent and ill-specified that trying to work around the bugs in it is likely to just be a neverending source of bugs.
Unfortunately the git devs have so far ignored my bug report despite it having an easy test case needing nothing more than a simple shell script to reproduce. And there are plenty of differently broken git versions out there even if they eventually fix it, so it seems git-annex has to deal with this mess somehow.
I'm going with not using
GIT_PREFIX
forGIT_DIR
and not forGIT_WORK_TREE=.
and hope that's enough.