Please describe the problem.
I do not remember trying to add that file "unlocked" anyhow, but git-annex, upon 2nd invocation of git status flips the file claiming it should get to the "unlocked" git link from original symlink:
❯ git annex version
git-annex version: 10.20240531+git214-g28f5c47b5a-1~ndall+1
❯ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
no changes added to commit (use "git add" and/or "git commit -a")
❯ git reset --hard
HEAD is now at 8700315 BF: fix leftover merge conflict in CONTRIBUTING.rst
so here from a clean state on first git status we get to dirty on subsequent:
❯ git status
git-annex: git status will show samples/UK_gla_3T_fMRI_consent_form_v3.0.docx to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
❯ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
no changes added to commit (use "git add" and/or "git commit -a")
❯ git diff
diff --git a/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx b/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
index 3215574..488e63f 100644
--- a/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
+++ b/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
@@ -1 +1 @@
-../.git/annex/objects/5M/wv/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx
\ No newline at end of file
+/annex/objects/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx
❯ git annex restage
restage ok
❯ git diff
❯ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
❯ git diff --cached
diff --git a/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx b/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
index 3215574..488e63f 100644
--- a/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
+++ b/samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
@@ -1 +1 @@
-../.git/annex/objects/5M/wv/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx
\ No newline at end of file
+/annex/objects/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx
This is on a local long-lived clone of http://github.com/con/open-brain-consent but seems to not happen on a fresh clone. So must be something about local "state".
Not sure if relates to the following issue under current investigation (but not yet addressed):
All I'm seeing here is a file that was locked and has gotten unlocked somehow.
The new and old versions of the file in
git diffare the same key, so this is not the same as the "inception" bug.Was the assistant running in this repository?
If you're using the assistant, it's certainly possible that something that it observed happening on disk prompted it to restage the file. And the assistant always stages files unlocked.
FWIW - no assistant running - reproduces still with 10.20250102+git5-ge8e36a90c1-1~ndall+1 - reproduces on a full copy. I will send email with a URL (not sure if there are any secrets there, so do not want to send publicly)
Ok, thanks for the test case. I can reproduce it with that.
The file is actually unlocked already in the first commit of it to git, as can be seen in its file permissions:
Somewhat weirdly, while that file is not a symlink, it has the form of a git-annex symlink target rather than an unlocked pointer file:
That unusual content of a pointer file is still something git-annex can handle, because it happens to use the same code path to parse a link target and a pointer file.
This explains why the file gets a modification staged: The file's annexed content is present, so the smudge clean filter and restage happens. In this case, the smudge clean filter emits a usual annex link, which is different than the file's previous content. Which is why it ends up with a modification staged.
What you should probably do is just commit the change that git-annex staged, converting it to a usual unlocked file. Or lock the file is you want it locked. Once it's in a usual state, this will stop being a problem.
Perhaps git-annex could probably avoid staging a modification in this case. Although there are several code paths where a pointer file can be written and/or staged, and all of them would have to take care to handle this case, which I think would mean extra work and slow it down for everyone.
And, I don't know how the file got into this state in the first place, perhaps some other bug or weird behavior?
Getting a file into this state can be done like this:
How the symlink bit might have gotten lost in real life, I don't know though.
So as far as I know this bug can only happen if something causes git to lose the symlink bit. Which would be a git bug, or perhaps some misbehavior on a fileystem like FAT?
Since git-annex's behavior is to stage a change that fixes the file to be a proper annex pointer file, a user who encounters whatever this is only has to make a commit to get out of the weird situation.
Unless we have a repeatable way for that to happen, that is not a git bug, it's hard for me to justify making git-annex slow in order to deal with it better.
Somewhat unrelated and I feel like I might have even proposed smth like that -- wouldn't it be useful if git-annex did add its version and potentially filesystem detail (if cheaply known) within its commit message to
git-annexbranch? unlessannex forgottenlater (and forgetting could summarize all the versions and filesystems used to that point), could have been useful here, or not?FWIW, sent a few related questions on versions etc to the author of the commit which introduced that file.