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

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

Browse source
This commit is contained in:
Joey Hess 2023-06-06 12:48:47 -04:00
commit 4c88f68061
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 116 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
doc/bugs/importtree_spends_hours_reading_cidsdb/comment_13_6043be5152ba2d44fb9aac4063060b56._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="jgoerzen"
avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
subject="comment 13"
date="2023-06-05T19:32:28Z"
content="""
My apologies for forgetting that.
So initially I thought it was after the last \"import source... ok\". I'm no longer convinced that it happens after the last one. There is clearly a phase before this starts, and a separate phase exhibiting this behavior.
The last output from one of these runs was:
```
/acrypt/git-annex/bind-ro/testdata/dvd/var..redacted..: openBinaryFile: permission denied (Permission denied)
^Mok
Failed to import some files from source. Re-run command to resume import.
```
And indeed there were about 2 dozen files out of that source set that it didn't have the permission to read.
I'm sorry it looked like expansion of scope. This is not really on NTFS; it's still on ZFS as it has been from the beginning. I had been testing with one of the repos on NTFS previously but in an effort to rule that out, I've been 100% on ZFS since before reporting this issue. \"acrypt\" is just the name of my ZFS pool and that refers to that it's atop LUKS (I don't believe this to be relevant, since the CPU time is in git-annex, not kcryptd)
"""]]

20
doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_4_4097e8dde9d9fe29b540112f7400689a._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="Mowgli"
avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
subject="comment igendwas"
date="2023-06-05T20:33:42Z"
content="""
> If git-annex metadata contains unicode and you enter a view, git-annex is operating acceptably when it preserves that unicode in the viewed filename.
But in this case, the metadata does NOT contain unicode/utf-8/whatever exotic charset. It contains ASCII, plain ASCII and git-annex is doing something with it that is not expetable.
> Maybe git-annex could try to transliterate unicode in viewed filenames in some way to work better non-unicode locales. But the locale can change. And git-annex needs to be able to reverse view filenames back to the filename used on the viewed branch. So it's not practical to vary the view filenames to fit the locale, because that would prevent that reversing from working unless it had a way to determine that locale that was in use when the view was generated.
It gets even more strange. I tried to rename the files, replacing the strange chars with just a `:`. Git was happy with it, my eyes was happy with it, my filesystem was happy with it but git-annex added now a second tag, additional to the content `:`, that is already there, it created the same key with a value of `ï¹?`. So it is even inconsistent in that case of renaming.
> git-annex has to replace the / character with something when generating a viewed file from metadata that contains that character. It used to use %, since that at least contains a slash, but I didn't think that was very readable. The unicode slash character it uses is very readable for the vast percentage of users who are not stuck with 1980's era displays.
Another opportunity is to abort and tell the user that this char is not allowed in current filesystem. Or give the user a opportunity to replace it with his own choice.
But I did not speak of the slash, I spoke about a double point (`:`). That is a fully legal character in mature filesystems (the most). With that windows filesystems, you mentioned, you have even other troubles that is more important like symlinks...
"""]]

10
doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_5_5e5441cca2f3bbc252029aca358e9a47._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="Mowgli"
avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
subject="comment 5"
date="2023-06-05T20:35:19Z"
content="""
> Sorry, it's simply a tradeoff between you and everyone else.
Well, the majority would use git-annex on proper filesystems. It is only a minority that still uses such broken filesystems that do not allow a double point.
"""]]

43
doc/todo/Make_addunlocked_configurable_like_largefiles.mdwn Normal file
View file

@ -0,0 +1,43 @@
Hi joey,
How about making `annex.addunlocked` configurable similar to `annex.largefiles` so different file types can be configured to be added unlocked and others locked?
The following illustrates a use case:
[[!format bash """
#!/bin/sh -x
# make a repo
export LC_ALL=C.UTF-8
chmod -R +w addunlocked;rm -rf addunlocked
git init addunlocked
cd addunlocked
git annex init
# configure *.txt files to be added unlocked so they stay editable
echo '*.txt annex.addunlocked=true' > .gitattributes
git add .gitattributes
git commit -m "Add .gitattributes"
# make a note
echo bla > notes.txt
git annex add
git annex sync -m "add notes.txt"
# However editing doesn't work as it was added locked
echo blubb >> notes.txt # fails as it was not added unlocked
"""]]
Probably not all matching options (like `copies` for example) make sense or work at all in this context, but at least `include=` would be useful („all files in that dir should be added unlocked always”). For example, in a synced folder for collaboration, PDFs could stay locked to save space, but Spreadsheets and ODT documents for example make sense to be added unlocked by default to stay editable. This could be achieved with something like this:
[[!format bash """
# repo-wide stored in git-annex branch
git annex config --set annex.addunlocked 'include=*.odt or include=**.pdf'
# folder-specific via .gitattributes
echo '*.pdf annex.addunlocked=true' >> .gitattributes # (or 'anything')
echo '*.odt annex.addunlocked=true' >> .gitattributes # (or 'anything')
# repo-specific
git config annex.addunlocked 'include=**/*.odt or include=**/*.pdf'
"""]]
What do you think?
Cheers, Yann

19
doc/todo/Make_addunlocked_configurable_like_largefiles/comment_1_823bddc3b3824419f1123748f163e0ff._comment Normal file
View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="nobodyinperson"
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
subject="comment 1"
date="2023-06-06T12:54:35Z"
content="""
[git annex matching options](https://git-annex.branchable.com/git-annex-matching-options/) that make sense for `annex.addunlocked`:
- include
- exclude
- mimetype
- mimeencoding
- largerthan
- smallerthan
- (securehash)
- (inbackend)
All the others won't work AFAICS because location tracking hasn't yet happened at adding time.
"""]]