Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2021-01-04 11:57:29 -04:00
commit 409eeed014
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 57 additions and 0 deletions

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="AlbertZeyer"
avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
subject="comment 6"
date="2021-01-02T23:49:14Z"
content="""
I'm having a very similar issue. Adding files is quite slow, and it hangs for several minutes in `(recording state in git...)` now (that started after adding quite a few files already), and the time seems to increase (I fear that it will soon be hours, not minutes, making it basically unusable...).
I have not really configured anything (i.e. it should use all the defaults). I just did `git init` and `git annex init`, and then started to import files using `git annex import`. That's all.
I don't really know about this smudge thing. Is that enabled by default? If that is causing problems, should I maybe disable it?
"""]]

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="AlbertZeyer"
avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
subject="comment 4"
date="2021-01-04T12:04:04Z"
content="""
That is the best solution with `find`? There is no reverse index? I made a separate forum entry for this question [here](https://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/), to discuss that a bit more separately.
Why exactly does `git annex sync` (or other ops) get slower on bigger repos? In principle it could be implemented in a way that it should not get slower (basically always avoiding any need to iterate through all objects, which should always be possible to avoid by having some indices for any operations which needs that).
Does it make sense to split up the repo, but share the Git Annex object files (shared `.git/annex/objects`)?
"""]]

View file

@ -0,0 +1,8 @@
I understand from [here](https://git-annex.branchable.com/forum/Import_existing_files/#comment-29ece0290fa1314ca48caf8f435570d2) that there is no reverse index from a key to list of file paths pointing to that key (i.e. pointing to the value).
`find . -lname '*<key>'` would be an extremely slow operation on a big repo as it would go through the whole repo. And this is probably a common operation I frequently want to do.
What if I would want to build one? How would I make sure that potential moves/renames will update the index?
I understand from [here](https://git-annex.branchable.com/git-annex-metadata/) that you can attach meta information to a key (via `git annex metadata`). This sounds as it would be useful to contain such reverse information, right?

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="AlbertZeyer"
avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
subject="comment 10"
date="2021-01-03T22:07:02Z"
content="""
From this man page, it's not totally clear how/where the metadata is stored. Is it inside the Git repo (i.e. as regular file), or inside the Annex, or somewhere else? Is this information synced when you do `git push` (as part of Git), or via `git annex sync`?
How does it resolve any conflicts?
Is the metadata itself under version control? (If it is in Git itself, then clearly yes, but that's not clear to me.)
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="AlbertZeyer"
avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
subject="comment 6"
date="2021-01-03T21:48:50Z"
content="""
Renaming files is still somewhat unclear then. So I should just use `git mv` to rename files?
What if the file extension changes? E.g. I have lots of pictures with uppercase `.JPG` and I might want to change them to `.jpg`. I might also have some files as `.jpeg` and to unify them, I might change them as well to `.jpg`. But as far as I understand, that would also change the default hash, as the default hash contains the extension? But doing `git mv` will take care about all of that via pre-commit hooks?
"""]]