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 2021-07-13 12:19:21 -04:00
commit 7b615c6bc4
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 42 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
doc/todo/add_maxextensionlength_to_git-annex-config/comment_5_9499ecd6136102803f1d6691c03e6b20._comment Normal file
View file

@ -0,0 +1,26 @@
[[!comment format=mdwn
username="jkniiv@b330fc3a602d36a37a67b2a2d99d4bed3bb653cb"
nickname="jkniiv"
avatar="http://cdn.libravatar.org/avatar/419f2eee8b0c37256488fabcc2737ff2"
subject="comment 5"
date="2021-07-12T22:48:25Z"
content="""
_joey:_
> It's already possible to configure the backend via .gitattributes;
Thanks for reminding me about that option. I shall use the .gitattributes trick to shorten
my init-git-annex.cmd script. :)
_joey:_
> It should probably be hard capped to something sensible.
As long as that sensible setting is >= 8 as that is a lower bound is what I use. I tend to think
that at most two extension components is what you usually need for identifying a file's \"type\" (think \".tar.gz\").
As for the length of a component, Windows (and probably other modern desktop environments) produces
for instance such extensions as \".search-ms\" (9 characters excluding the dot) for saved Explorer searches.
I don't think that's an unreasonably long extension component for this use case. For more standard file types
to be exchanged via public methods maybe at most five characters per component should be the maximum. However,
git-annex should be lenient towards what it accepts as long as that is reasonably possible to uphold. IMHO, a practical
upper limit for annex.maxextensionlength could be 16 to 20 characters.
"""]]

8
doc/todo/add_maxextensionlength_to_git-annex-config/comment_6_9ff852c12549985f6e88bd2316a69def._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="(partial) filenames in keys"
date="2021-07-13T15:13:27Z"
content="""
WOM and URL keys [[already contain|backends]] filenames or parts of filenames. Docs warn that too-long keys might cause issues on Windows, but also that 512 and 384 length hashes already have that problem. So it seems that permitting larger `maxextensionlength` should not add new issues?
"""]]

8
doc/todo/additional_git-annex-config_settings__63__/comment_7_c1768ab8568c8e58525ed40e76cc13f2._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 7"
date="2021-07-13T03:05:45Z"
content="""
Realized that for the use case I was thinking of -- setting repo-wide policies such as locked-files-only -- git-annex-config isn't right, since the value can be changed by any clone. For that use case, have to configure hooks/triggers on the central repo to reject pull requests that break the policy.
"""]]