Added a comment
authorberyllium@5bc3c32eb8156390f96e363e4ba38976567425ec <beryllium@web>
Mon, 5 May 2025 11:14:00 +0000 (11:14 +0000)
committeradmin <admin@branchable.com>
Mon, 5 May 2025 11:14:00 +0000 (11:14 +0000)
doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_2_12027298596113544eed90a0f0cff626._comment [new file with mode: 0644]

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_2_12027298596113544eed90a0f0cff626._comment b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_2_12027298596113544eed90a0f0cff626._comment
new file mode 100644 (file)
index 0000000..60a0f8d
--- /dev/null
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 2"
+ date="2025-05-05T11:13:59Z"
+ content="""
+Thank you. For your kindness, I think I owe a better explanation.
+
+It might be being a little ambitious... but I am trying to work on a git-annex where I am indexing retired internal drives. Performing a git-annex import --no-content on each setup importtree=yes remote, and then merging/fast-forwarding to a git checkout --orphan'ed branch.
+
+Key point is, now, for example, I want to find out where a file might have been duplicated.
+
+I have considered your idea of the --historical switch. But perhaps related to <https://git-annex.branchable.com/bugs/whereused_--key_forcing_--historical._exportree__63__/>, I have experienced strange behaviour, now and in the past.
+
+The following sequence might explain.
+
+```
+$ git rev-parse --abbrev-ref HEAD
+master
+$ ls
+$ # no files, because only branches with unrelated histories available
+$ git-annex whereused --key SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+$ # not unusual
+```
+
+Now with historical:
+
+```
+$ git-annex whereused --historical --key SHA256E
+-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+warning: exhaustive rename detection was skipped due to too many files.
+warning: you may want to set your diff.renameLimit variable to at least 115576 and retry the command.
+SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp ntfs,uuid=E06053EC6053C7C4~2:Program Files/Common Files/Services/verisign.bmp
+$ # this is good, but not exhaustive
+$ # plus it includes the weird to me, but perhaps explainable offset
+$ # i do prune and curate these branches after merging
+```
+
+To demonstrate that this isn't a exhaustive search, here I am following your suggestion on using git rev-list
+
+```
+$ git rev-list --objects --no-object-names --no-walk ntfs,uuid=E06053EC6053C7C4 | git annex lookupkey --ref --batch | grep SHA256E-s2702--7f79dade5c9f7c6851af225b
+e7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+$ # confirming --historical find
+$ git rev-list --objects --no-object-names --no-walk ntfs,uuid=01D20F52B11B58A0 | git annex lookupkey --ref --batch | grep SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d
+88b62259ed251638ba0140c7ea311cf2ed.bmp
+SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+$ # as you can see, the only technique that sort of works is if your technique
+$ # iterated over all branches
+```
+
+Thank you again, because I do have something to work with now in any case.
+
+"""]]