mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2025-01-09 11:46:53 -04:00
parent 36ea3287b6
commit 71abda0625
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 41 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

41
doc/bugs/keeps_trying_to_commit_file_unlocked/comment_3_1a6120c92f6104623432a60886cc628e._comment Normal file
View file

@ -0,0 +1,41 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2025-01-09T14:46:37Z"
content="""
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:
joey@darkstar:~/tmp/open-brain-consent>git ls-tree -r f50cc382241662613b86073a2c001398e30c120f|grep samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
100644 blob 3215574fde295d53dc0032ec65e826236a2f2758 samples/UK_gla_3T_fMRI_consent_form_v3.0.docx
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:
joey@darkstar:~/tmp/open-brain-consent>cat samples/UK_gla_3T_fMRI_consent_form_v3.0.docx; echo
../.git/annex/objects/5M/wv/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx/MD5E-s591826--1ca9251906259623f73a3aba47ef6369.0.docx
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?
"""]]