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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
A git post-update hook can run git-annex merge and so make all pushes
into a repository update its working tree.
But, there are some complications to writing that hook. See
<http://git-annex.branchable.com/tips/setup_a_public_repository_on_a_web_site/>
IIRC different versions of git may behave differently.
And, such a hook can't be used on a filesystem that doesn't support
executables. (Except on Windows which has a workaround to allow
non-executable hooks.)
Could there be a single command that sets it up? Something like
`git annex merge --run-automatically`
That could install the hook, and also set an annex.automerge config.
The config could be checked by git-annex sync (and assistant) when pushing
to a local remote, and they could perform a merge on the remote. This way,
it would work for repos on removable drives that don't support execute
bits. (Ssh remotes on such filesystems would not be handled, but that's a
rare configuration; the hook would handle ssh remotes on non-crippled
filesystems, and on Windows.)
---
Alternatively, receive.denyCurrentBranch can be set to updateInstead.
With this configuration, `git annex sync` automatically updates the
work-tree of the remote already.
This wouldn't work for direct mode repositories, which are often used
on removable drives, since git thinks they're bare repos.
Nor will it work for adjusted branches, since the adjusted branch is not
updated by the push.
---
Could the updateInstead configuration be made to work for direct mode and
adjusted branches? Could install a post-update hook, that runs a git-annex
command that checks for updateInstead, and emulates its behavior, handling
direct mode and adjusted branches.
To support direct mode repos on removable drives w/o execute bits,
could make sync check local remotes and run the equivilant action as the
hook would run.
To fully emulate updateInstead, the post-update hook
should abort if the tree is unclean or if there are merge conflicts.
But, in a direct mode repo, the only way the user will likely resolve such
a situation is git-annex sync/merge, so the hook could just run git-annex
merge instead of trying to fully emulate regular updateInstead behavior.
Similarly, in an adjusted branch, the push will update master, and git
annex sync/merge is what the user will likely do. Although they could
choose to reset changes to the tree.
---
Potential least surprise violation:
If a repository is updating when git annex pushes changes to it,
the user might also expect that the same git annex sync
would pull changes from that repository. Even though nothing has been
run on the repository to commit changes made there.
Particularly when the assistant is being used, this seems an easy confusion
to have. In one clone the user sees every file change getting committed
and synced around, so why would that not happen in the other clone, on the
removable drive?
Keeping this a command-line setup, and not something the assistant does,
will avoid that confusion.
--[[Joey]]
> all above [[done]] --[[Joey]]
|
