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

close

Browse source
This commit is contained in:
Joey Hess 2021-01-29 13:24:28 -04:00
parent 02b5bd224e
commit 9bdcba9fcb
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 47 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key.mdwn
View file

@ -1 +1,3 @@
git-annex commands that take a file path as argument but really operate on the key corresponding to the file's contents, when given an unlocked file that has been modified, will operate on the original key, not the key corresponding to the file's current contents. For example, [[`git-annex-whereis`|git-annex-whereis]] can show that there are several copies of the contents, even though there is only one (and only in the working copy).
> [[closing|done]] as not a bug --[[Joey]]

45
doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key/comment_1_d7fc6d70675b2b001c47e69ea40a9f4d._comment Normal file
View file

@ -0,0 +1,45 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2021-01-29T17:12:50Z"
content="""
I don't think this has anything to do with unlocked files really,
and I think a v5 repo would have behaved the same way. A repo with the
smudge filter disabled certainly seems to:
joey@darkstar:/tmp/bbb>rm .git/info/attributes
joey@darkstar:/tmp/bbb>date > bar
joey@darkstar:/tmp/bbb>git annex add bar
add bar
ok
(recording state in git...)
ijoey@darkstar:/tmp/bbb>git commit -m add
[master 342b357] add
1 file changed, 1 insertion(+)
create mode 120000 bar
joey@darkstar:/tmp/bbb>git annex copy bar --to origin
copy bar (to origin...)
(checksum...) iok
(recording state in git...)
joey@darkstar:/tmp/bbb>git annex whereis bar
whereis bar (2 copies)
4f1d49f8-aeea-47fc-8982-b17b6b2f136f -- joey@darkstar:/tmp/aaa [origin]
5861485c-0e5f-4eec-91b5-166dbb999c81 -- joey@darkstar:/tmp/bbb [here]
ok
joey@darkstar:/tmp/bbb>rm bar
joey@darkstar:/tmp/bbb>date > bar
joey@darkstar:/tmp/bbb>git annex whereis bar
whereis bar (2 copies)
4f1d49f8-aeea-47fc-8982-b17b6b2f136f -- joey@darkstar:/tmp/aaa [origin]
5861485c-0e5f-4eec-91b5-166dbb999c81 -- joey@darkstar:/tmp/bbb [here]
ok
And this is consistent with git-annex working on information that is staged
in git, not on unstaged changes in the working tree.
joey@darkstar:/tmp/bbb>mv bar bar2
joey@darkstar:/tmp/bbb>git annex whereis bar2
joey@darkstar:/tmp/bbb>
So, I don't think this is a bug.
"""]]