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 2019-09-21 21:27:06 -04:00
commit 5e787b936b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
13 changed files with 205 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters.mdwn
View file

@ -13,4 +13,4 @@ proceeds just fine although one of the options is not anything that special remo
At least for the built in special remotes (not external) this should be possible and would help to avoid issues such as [OpenNeuroOrg/datalad-service/issues/67](https://github.com/OpenNeuroOrg/datalad-service/issues/67) etc. Ideally parameters verification should also be provisioned in external special remotes protocol.
[[!meta author=yoh]]
[[!meta project=dandi]]
[[!tag projects/dandi]]

8
doc/todo/git_smudge_clean_interface_suboptiomal/comment_3_778d21703afc5c08bfbc387b442cc193._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 3"
date="2019-09-20T20:46:41Z"
content="""
[git docs](https://git-scm.com/docs/gitattributes#_code_filter_code) say \"Depending on the version that is being filtered, the corresponding file on disk may not exist, or may have different contents. So, smudge and clean commands should not try to access the file on disk, but only act as filters on the content provided to them on standard input.\" Are there cases where this could cause problems?
"""]]

8
doc/todo/split_off_clean__47__smudge_filter__63__/comment_6_9e656e32ff2090aede8f403cb915e059._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 6"
date="2019-09-20T20:41:25Z"
content="""
\" Improving the interface to let the clean filter read the content of the file itself, rather than it being piped through, would be the best way to improve git add performance\" -- right, but that sounds unlikely near-term?
"""]]

28
doc/todo/universal_batch_mode/comment_2_c662c1e2410285e9bf6d01135851fdc8._comment Normal file
View file

@ -0,0 +1,28 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="found it"
date="2019-09-20T18:56:52Z"
content="""
see [datalad/issues/139](https://github.com/datalad/datalad/issues/139#issuecomment-97948143). Quoting a part of it:
*But I'd like to investigate adding --batch to individual commands first,
since this seems more git-like, and also simpler. It would probably be
helpful to talk about the specific commands you need to call a lot.*
*Things like `git annex lookupkey --batch`, `git-annex readpresentkey --batch`
etc should be able to be spun up and run as long-duration servers, which
you could query as needed, not batched up all at once. This is how
git-annex uses `git cat-file --batch` etc.*
*There's some potential for such a long-running command to either
buffer stale data so it doesn't answer with the current state of the
repository, or for it to buffer changes and not commit them to disk
immediately. For example, a `git annex add --batch` would have the
latter problem.*
*That is actually an argument for only adding --batch mode to specific
commands though, since that would be an opportunity to check thier
behavior. A single `git-annex shell` interface would expose any such
problems in all commands.*
"""]]