I am using this to synchronize my Markdown based notes files across machines. There are under a hundred files now so I haven't hit any issues in that department yet.
However, there is a gradual memory leak which persists even when I kill and restart my process. I observed this only on a KVM based Linux guest - not sure if this is because of inotify based listening but I'm going to have to dig deeper to find out.
The threads in lines 245-247 feel like they could deadlock or have a race, esp if changes happen nearly simultaneously on both ends, or if a change on one end is received and sync'ed to the other. I'm not sure how git handles multiple writes? Almost wonder if forking might cure the memory leak too or at least make it easier to see (see my other comment of some shell code).
I read that running multiple git commands at the same time on the same repo should be fine (I can't remember where I read this). It is probably better to synchronize regardless!
(while true
do
inotifywait \
--exclude '.*\.sw.' \
--recursive \
--event close_write \
--event delete \
--event moved_to \
--event moved_from \
dir1/
git push
sleep 0.1
done
) 2>&1 >/var/log/push_log.log &
(while true
do
cat << 'EOF' | ssh remotebox
inotifywait \
--exclude '.*\.sw.' \
--recursive \
--event close_write \
--event delete \
--event moved_to \
--event moved_from \
dir1/
git push #??
sleep 0.1
EOF # (second EOF cannot be indented)
done
) 2>&1 >/var/log/pull_log.log &
echo "Kicked off pull and push processes."
wait1. Make it work on OSX 2. Use a lock file to prevent multiple instances from running when I put this in crontab
I found watchman[0]. Got to see if I can use that in place of "inotifywait".