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

fix an old bug, open new bug I noticed while confirming the old bug was fixed

Browse source
This commit is contained in:
Joey Hess 2019-09-30 16:30:29 -04:00
parent 9df7718e15
commit 3b8c94fcbd
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 56 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

41
doc/bugs/add_of_modified_file_applies_annex.largefiles_to_size_of_old_key.mdwn Normal file
View file

@ -0,0 +1,41 @@
`git annex add` of an modified file when annex.largefiles is set
matches largerthan against the size of the old key, not the current
file size
mkdir /tmp/repo;
cd /tmp/repo;
git init;
git annex init;
git config annex.largefiles '(largerthan=5b)'
git add .gitattributes;
git commit -m 'added .gitattri';
echo 123456 > file;
git annex add file;
git commit -m add1;
#git config annex.largefiles '(largerthan=7b)'
git annex unlock file;
echo 123 >| file
git annex add file
This test case adds the file to the annex, even though it's smaller than
5b, because the old key is 6b. If the line is uncommented, it gets added to
git instead.
While the test case unlocks the file, deleting the annex link and writing
a new file and adding that has the same behavior.
Using `git add` also has the same behavior.
I'm pretty sure the user expects the file to be added to git in all
these situation. They configured annex.largefiles that way for a reason.
----
The root cause is that Limit.limitSize uses lookupFileKey.
It makes sense for that to look up the key and not look at the
current file content when it's being used by a preferred content expression,
or by --largerthan.
But, for matching largefiles, it needs to look at the actual file on disk,
not an old key.

2
doc/bugs/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now.mdwn
View file

@ -69,3 +69,5 @@ Expected behavior:
[[!meta author=yoh]] [[!meta author=yoh]]
[[!tag projects/datalad]] [[!tag projects/datalad]]
> [[fixed|done]] --[[Joey]]

13
doc/bugs/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_9_220be99862a8a24263bd5f5f27988a1c._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="joey"
subject="""comment 9"""
date="2019-09-30T19:43:43Z"
content="""
IIRC this involved v5 repositories and the pre-commit
hook's hacks to make v5 unlocked files work. Stuff that was one of the
motivations for v7.
I tried the script in a v7 repository, and the git commit
of the file succeeded, no "partial commit" complaint. So I think the
original bug is fixed.
"""]]