summaryrefslogtreecommitdiff
path: root/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment
blob: 2163ba76d5ba3eded17117eed7665b2f9d3c0c08 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
[[!comment format=mdwn
 username="helmut"
 ip="89.0.176.236"
 subject="Asynchronous hooks?"
 date="2012-10-13T09:46:14Z"
 content="""
Is there a way to use asynchronous remotes? Interaction with git annex would have to
split the part of initiating some action from completing it.

I imagine I could `git annex copy` a file to an asynchronous remote and the command
would almost immediately complete. Later I would learn that the transfer is
completed, so the hook must be able to record that information in the `git-annex`
branch. An additional plumbing command seems required here as well as a way to
indicate that even though the store-hook completed, the file is not transferred.

Similarly `git annex get` would immediately return without actually fetching the
file. This should already be possible by returning non-zero from the retrieve-hook.
Later the hook could use plumbing level commands to actually stick the received file
into the repository.

The remove-hook should need no changes, but the checkpresent-hook would be more like
a trigger without any actual result. The extension of the plumbing required for the
extension to the receive-hook could update the location log. A downside here is that
you never know when a fsck has completed.

My proposal does not include a way to track the completion of actions, but relies on
the hook to always complete them reliably. It is not clear that this is the best road
for asynchronous hooks.

One use case for this would be a remote that is only accessible via uucp. Are there
other use cases? Is the drafted interface useful?
"""]]