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

git bug

Browse source
This commit is contained in:
Joey Hess 2025-05-22 14:32:42 -04:00
parent fe1fe5eaec
commit 18d27920a3
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 49 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

49
doc/bugs/git_diff_in_adj_unlock_reports_diff_for_empty_file/comment_1_cb16c170d49b628cca0c76d8843b9f52._comment Normal file
View file

@ -0,0 +1,49 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2025-05-22T17:52:10Z"
content="""
A simplified test case, which works on any filesystem, not only crippled
filesystems:
#!/bin/sh
git init r
cd r
git annex init
git commit -m initial --allow-empty
git-annex adjust --unlock
touch emptyfile
git annex add emptyfile
git diff
The adjusted branch is not even needed. `git-annex add emptyfile`
followed by `git-annex unlock emptyfile` has the same result.
In this case, `git diff` is running the `git-annex smudge --clean`
filter every time. Which IIRC is a bug of some kind with git when
smudging empty files.
I've verified that `git-annex smudge --clean` behaves corretly.
It outputs the same annex link that was already staged. So git diff is
choosing for whatever reason to ignore what it output, and using ""
as the content of the file instead.
So, I think this is a git bug, which git-annex cannot work around.
See also [[bugs/Empty_files_make_git_status_slow]] which is about
the repeated and unncessary running of the smudge filter on empty files.
There I hypothesize that git treats 0 size in the index as an indication that it
doesn't know about the file, so generally mishandles empty files.
And see also [[bugs/resolvemerge_fails_when_unlocked_empty_files_exist]]
where I identified a related git bug, where an empty unlocked file causes
git to crash with an internal error, and reported it to the git developers.
Unfortunately, nobody ever responded to my bug report.
Perhaps the thing to do is for git-annex to refuse to store an empty file
as an unlocked file. It could still use annex symlinks for locked empty files,
but unlocking would necessarily switch to an empty file stored in git
the usual way. Unfortunately, that would make reverse adjusting an unlocked
branch not know if the file was intended to be annexed or not. Also, it doesn't
help for any repositories that already contain unlocked empty files.
"""]]