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.