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

todo

Browse source
This commit is contained in:
Joey Hess 2024-05-15 14:33:13 -04:00
parent 2dfffa0621
commit d24d8870c5
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 20 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
doc/todo/git-remote-annex.mdwn
View file

@ -10,6 +10,26 @@ will be available to users who don't use datalad.
This is implememented and working. Remaining todo list for it:
* Cloning writes the new special remote config into remote.log,
and *deletes* other special remote configs.
The remote config from the url may be slightly different as well
than the existing one. Cloning should not write it.
* The race condition described in
[[!commit 797f27ab0517e0021363791ff269300f2ba095a5]]
where before git-annex init is run in a repo,
using git-remote-annex and at the same time git-annex init can lose
changes that the latter command (and ones after it) write to the
git-annex branch.
This should be fixable by making git-remote-annex not write to the
git-annex branch, but to eg, a temporary journal directory.
Also, when the remote uses importtree=yes, pushing to it updates
content identifiers, which currently get recorded in the git-annex
branch. It would be good to avoid that being written as well.
* Test incremental push edge cases involving checkprereq.
* Cloning from an annex:: url with importtree=yes doesn't work
@ -68,24 +88,3 @@ This is implememented and working. Remaining todo list for it:
They would have to use git fetch --prune to notice the deletion.
Once the user does notice, they can re-push their ref to recover.
Can this be improved?
* The race condition described in
[[!commit 797f27ab0517e0021363791ff269300f2ba095a5]]
where before git-annex init is run in a repo,
using git-remote-annex and at the same time git-annex init can lose
changes that the latter command (and ones after it) write to the
git-annex branch.
This should be fixable by making git-remote-annex not write to the
git-annex branch, but to eg, a temporary journal directory.
Also, cloning currently writes the special remote config into remote.log,
which might be slightly different in some way than the config in
remote.log for the same remote. cloning should not change the stored
config of a remote, but that branch write was necessary. So throwing
away the branch write is also good for this case.
Also, when the remote uses importtree=yes, pushing to it updates
content identifiers, which currently get recorded in the git-annex
branch. It would be good to avoid that being written as well.