From 9bdcba9fcbcf2a2252a24307d4a8eec3d8aa4219 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 29 Jan 2021 13:24:28 -0400 Subject: [PATCH] close --- ...ed__44___changed_file_use_its_old_key.mdwn | 2 + ..._d7fc6d70675b2b001c47e69ea40a9f4d._comment | 45 +++++++++++++++++++ 2 files changed, 47 insertions(+) create mode 100644 doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key/comment_1_d7fc6d70675b2b001c47e69ea40a9f4d._comment diff --git a/doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key.mdwn b/doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key.mdwn index 91640791d7..296f3ab549 100644 --- a/doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key.mdwn +++ b/doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key.mdwn @@ -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]] diff --git a/doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key/comment_1_d7fc6d70675b2b001c47e69ea40a9f4d._comment b/doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key/comment_1_d7fc6d70675b2b001c47e69ea40a9f4d._comment new file mode 100644 index 0000000000..269023272d --- /dev/null +++ b/doc/bugs/commands_on_unlocked__44___changed_file_use_its_old_key/comment_1_d7fc6d70675b2b001c47e69ea40a9f4d._comment @@ -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. +"""]] -- 2.30.2