tag todos potentially useful for datalad
This commit is contained in:
parent
0ccf436795
commit
42b381e4b2
12 changed files with 20 additions and 0 deletions
6
doc/projects/datalad/potential.mdwn
Normal file
6
doc/projects/datalad/potential.mdwn
Normal file
|
@ -0,0 +1,6 @@
|
|||
These are TODOs that have been tagged as potentially being useful for
|
||||
[[/projects/DataLad]] or a related project to fund work on.
|
||||
|
||||
[[!inline pages="todo/* and !todo/done and !link(todo/done) and
|
||||
tagged(projects/datalad/potential))" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
|
||||
|
|
@ -19,3 +19,4 @@ Couldn't the [separate-git-tree-for-diffing-technique you used lately to speed u
|
|||
One problem I see with this tough is that it wouldn't be possible to cache the user's `.git/info/attributes` settings, which can change independently.
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -18,3 +18,4 @@ So I have yet another idea to speed up git annex. For now only for the 2nd pass
|
|||
2. Again, update the commit id of remotes that we successfully synced with.
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -14,6 +14,9 @@ What I'd like to do is implement this in concert with someone who is
|
|||
implementing a special remote that uses it. So we can iterate on the
|
||||
protocol as needed to make it better. --[[Joey]]
|
||||
|
||||
> @mih expressed some interest in this in [a comment](https://git-annex.branchable.com/design/external_special_remote_protocol/export_and_import_appendix/#comment-d0cffbe55870a469052ebb7ed36f8300)
|
||||
> so maybe him? --[[Joey]]
|
||||
|
||||
I do want to implement this though, assuming it turns out to be feasible
|
||||
for people to implement it despite its complexity, so I'm tagging this confirmed.
|
||||
|
||||
|
@ -22,3 +25,4 @@ although it might make sense to implement that as a simpler protocol
|
|||
extension.)
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -29,3 +29,4 @@ from the remote.
|
|||
> file to be deleted from master.
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -50,3 +50,4 @@ Note that the protocol does allow querying with GETCONFIG etc before
|
|||
responding to a WHEREIS request.
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -7,3 +7,4 @@ Which is caused by the fact that I didn't have checked out the files on my works
|
|||
Is there a reason that does not exist and if so what would be a way to do sending files to the android device without ssh-ing into my server?
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -76,3 +76,4 @@ Or by complicating Remote.Helper.ExportImport further..
|
|||
--[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -105,3 +105,4 @@ easy to fix up a git commit history to remove an unwanted commit.
|
|||
Does annex.resolvemerge meet criteria #1? --[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -31,3 +31,4 @@ running it on at least some of the autobuilders might be a good way.
|
|||
--[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -6,3 +6,4 @@ For example, I use git annex for very large scientific tomographic datasets and
|
|||
Though, I guess, it would be possible to write a special remote wrapper for this, I wonder if this might qualify as an officially supported option to the already existing special remotes like "directory" or "rsync". E.g. in conjunction to `encryption` something like `compression` with possible values like `pbzip`, `bzip`, `pigz` and `gzip`.
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
|
@ -10,3 +10,4 @@ extended to cover the additional actions. --[[Joey]]
|
|||
> on. --[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
[[!tag projects/datalad/potential]]
|
||||
|
|
Loading…
Add table
Reference in a new issue