On DragonflyBSD with git-annex built with ghc 8.10.7, a simple git annex add
puts strange entries in the index, as shown:
copter-dfly tmp $ mkdir d
copter-dfly tmp $ cd d
copter-dfly d $ git init
Initialized empty Git repository in /home/falsifian/tmp/d/.git/
copter-dfly d $ git annex init
init ok
(recording state in git...)
copter-dfly d $ echo test>f
copter-dfly d $ git annex add f
add f
ok
(recording state in git...)
copter-dfly d $ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: 30d/f3a/SHA256-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2.log
new file: f
new file: uuid.log
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: 30d/f3a/SHA256-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2.log
deleted: uuid.log
copter-dfly d $
Digging into it further with dfly people over IRC, it's been discovered:
- The bug does not appear with ghc 8.10.5, with git-annex 20210903 or 20210223.
- But it consistently happens with ghc 8.10.7, with all the versions I tried.
- I also noticed that
git annex init
does not create the file.git/annex/index
when the bug is present.
Has anyone tried git-annex with ghc 8.10.7 on a different OS?
I tried to figure out why .git/annex/index
was not being created, but I had some trouble figuring out which line of code is supposed to create it. If someone could point me there I could do some further debugging to see why it isn't created.
It seems that somehow it is failing to set environment variables. Eg,
GIT_INDEX_FILE
is what makes git use.git/annex/index
and if it was not set it would behave as you describe.This strongly suggests that there is a bug in the compiler/libraries.
Here is a small test program:
If run with "runghc foo.hs", that should output "testing: foo" and then "testing: bar".
On Linux this problem does not occur.
I built git-annex with ghc-8.10.7 by changing the stack.yaml to use "resolver: lts-18.20" and running "stack build".
Looks like you are right. Thanks for the help! On DragonFlyBSD with ghc 8.10.7 I see:
I guess it is time to look at the
System.Process
module.