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-03-23 15:47:21 -04:00
commit 806b6f77b9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 28 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_a5089531b5d9bdcc90a07cb9d3f1da7d._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 6"
date="2021-03-23T18:43:30Z"
content="""
> I've added an annex.supportunlocked config that can be set
you are talking about a regular `git config` configuration variable? then FWIW it is of no use for the original use case of a user cloning an existing git-annex repo since I would have no clue if that repository contains any unlocked files or not. It could indeed come handy for timing when desired to investigate.
I am yet to appreciate how \"repo-global config\" situation would be different from handling any other git-annex manipulation within `git-annex` branch (e.g. of annex config there) where we already rely on git-annex to \"do the right thing\" (deciding on taking keys availability information based on timestamping etc).
"""]]

16
doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_7_71d3936dc37349392e6f7b0bd8292b7b._comment Normal file
View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="annex.supportunlocked"
date="2021-03-23T19:30:39Z"
content="""
Thanks for adding `annex.supportunlocked`!
It seems to me that this is a repo property that you'd want to be consistent across clones, i.e. a candidate for a [[`git-annex-config`|git-annex-config]] setting.
\"there's no way for git-annex to enforce that a repo doesn't contain unlocked files\" -- maybe, have [[`git-annex-fsck`|git-annex-fsck]] check that there are none if `annex.supportunlocked` is set?
\"git add with a largefiles configuration... would need to ignore the largefiles configuration and add the file to git\" -- which the `annex.gitaddtoannex` config setting already does, so maybe just document that `annex.supportunlocked=false` implies `annex.gitaddtoannex=false`? Could you then uninstall (or skip installing) the smudge/clean filters?
\"someone could merge new unlocked files from a repo that does, using just git\" -- they can't do that inadvertently if the repo has a `git-annex-config` setting disallowing the adding of unlocked files. If they manually override the repo setting, or \"convert symlinks to unlocked files manually\", they're doing something odd you can't plan for anyway.
"""]]