If you have the space, you could keep a local copy of the remote hierarchy. When your inotify triggers due to a change in your real hierarchy you can use
rsync -a -i between the real and local copy to update it and generate a list of actual changes. Apply just this list to rsync update the remote from the local copy.
To help with this scenario, see the rsync man page BATCH MODE section. Instead of the
-i you do
rsync -a --write-batch=foo between the real and local copy, then do
rsync -a --read-batch=foo to the remote to apply exactly the same changes. (The foo file is a binary file containing a copy of all the changes).
Here's an example in /tmp using dirs a, b, and c, where a is your real directory where you edit files, b is a local cached copy of the remote, and c is the remote. We create a and copy it to b and c to start with. I've put c in a variable so it can be changed later.
cd /tmp || exit
echo do: rm -fr a b c foo foo.sh
echo hi >a/f1
echo hi >a/f2
rsync -av a/ b
rsync -av a/ "$c"
We have 3 identical directories. We edit dir a.
echo bye >>a/f1
echo bye >>a/f3
rm -f a/f2
We rsync a to b, create a batch file foo:
rsync -av --delete --write-batch=/tmp/foo a/ b
We can now rerun the changes saved in foo on c:
rsync -av --delete --read-batch=/tmp/foo "$c"
There are now again 3 identical directories. The advantage is that rsync will only do the updates it recorded in the foo file.
I tried this using a local ftp gvfs mount for c, but it didn't work (
c="$XDG_RUNTIME_DIR/gvfs/ftp:host=localhost,user=ftp/test/"). The gvfsd-fuse mount seems very buggy and assumes sometimes that a remote file should be a directory, so rsync never worked with it.