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

Merge branch 'master' into bs

Browse source 
and update changelog
This commit is contained in:
Joey Hess 2019-12-18 15:13:30 -04:00
commit 7d9dff5b05
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
16 changed files with 263 additions and 48 deletions
Download patch file Download diff file Expand all files Collapse all files

15
doc/todo/git-annex-cat/comment_1_a5da8264c2d662e96802535820cb2249._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="https://christian.amsuess.com/chrysn"
nickname="chrysn"
avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
subject="Would be useful"
date="2019-12-17T09:08:08Z"
content="""
A `git annex cat` would be useful for the very web server purpose you describe (WIP at https://gitlab.com/chrysn/annex-to-web, though I'm not sure it's going anywhere).
Unlike `git annex inprogress` that I (will) use for a workaround, this could take a `--skip` argument that usually just seeks into the file.
If the data is served from a remote that allows seeking access (eg. IPFS),
then that access could be priorized and that part downloaded first.
(Implementing this would require another tmp pool for sparse files as they couldn't go with the `git annex inprogress` files for there is the expectation that those would grow to completion,
but anyway this would be an entry point for such a feature if it is ever added).
"""]]

10
doc/todo/git-annex-cat/comment_2_a43a3568e48e6b5e93998bc473178d5c._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2019-12-18T17:49:47Z"
content="""
git-annex's API for getting object content from remotes involve a
destination file that is written to. That limits the efficiency of such a
command. There would need to be a separate API for streaming, which some
remotes will not have any hope of supporting.
"""]]

10
doc/todo/git-annex-inprogress_--key.mdwn Normal file
View file

@ -0,0 +1,10 @@
Unlike `whereis` and other subcommands, `inprogress` does not offer a `--key` argument to select files by key rather than checked-out name,
making it unusable in bare repositories.
Please consider adding a `--key` option there, which would display the single incomplete file corresponding to the key if one is in progress.
My use case is serving git-annexed files to the web from a bare repository (<https://gitlab.com/chrysn/annex-to-web>, see also [[todo/git-annex-cat]]), which would be especially useful with gitolite repositories as they are by design bare, and on devices where checkouts are cumbersome (cf. [[forum/Dealing_with_crippled_Android_file_system]]).
A workaround is running `git annex inprogress --all | grep $KEY`, but that's probably relying on an implementation detail that could be changed at any time (though it probably won't as to avoid race conditions as in `tail -f $(git annex inprogress file-thats-almost.done)`).
> [[done]] --[[Joey]]

5
doc/todo/making_it_easier_to_smudge_dotfiles.mdwn Normal file
View file

@ -0,0 +1,5 @@
I want to add some dotfiles in the root of my repository to git-annex as unlocked annexed files. So I edited `.git/info/attributes` to remove the line `.* !filter`, such that it only contains the line `* filter=annex`. This seems to be working fine.
I was thinking that it might make sense to have a `git annex config` option to tell git-annex not to add the `.* !filter` line to `.git/info/attributes` when initialising other clones of this repo. In the meantime, I've worked around it using a `post_checkout` hook in my `~/.mrconfig` which edits `.git/info/attributes`.
--spwhitton