well actually the most important stuff is my point 3, you might want to read
that first. It could make all else moot.
1) line 431: why the break? why stop processing?
what if there are more events following? for example: rm, add, rm ?
shouldn't we always process until we find the very last (most recent) event in
Intuitively it seems to me the most recent event is the most important (as it
describes the most recent state of the file in question; as in, is the file on
the filesystem or not)
but at the same time, I guess it's possible a different event happened which
doesn't fit in the coalesce window, causing the file to be in a different state
then what the event says. (file removed, but then readded, but the add is
outside the coalesce window, then obviously we shouldn't "git rm" the file)
this brings me to my next point:
INFO:root:Coalesce event triggered for file /home/dieter/.local/share/pim/4913
DEBUG:root:Considering file /home/dieter/.local/share/pim/4913, which has the
following events recorded:
DEBUG:root: Event type=IN_ATTRIB, action=git add %s
DEBUG:root: Event type=IN_CLOSE_WRITE, action=git add %s
DEBUG:root: Event type=IN_DELETE, action=git rm %s
INFO:root:Final action for file /home/dieter/.local/share/pim/4913:
type=IN_ATTRIB, action=git add %s
INFO:root:NOTIFICATION: Local change: Committing changes in
/home/dieter/.local/share/pim/4913: git add %s
DEBUG:root:Substituting cmd part %s with /home/dieter/.local/share/pim/4913
INFO:root:Coalesce event triggered for file /home/dieter/.local/share/pim/test
WARNING:root:NOTIFICATION: Command failed: Command 'git add
/home/dieter/.local/share/pim/4913' in '/home/dieter/.local/share/pim' failed.
fatal: pathspec '4913' did not match any files
"4913" is a tmp file created and deleted by vim when editing a file.
( see https://bugzilla.redhat.com/show_bug.cgi?id=427711 )
git add has a "--ignore-missing" flag but it's only allowed in dry run
(why?). There's also "--ignore-errors" but we don't want to ignore *all*
errors, and this still exists >0 anyway.
we attempted to fix this but the current fix is vulnerable to race
discussions as explained @
3) thinking about all this stuff further, imagine git had a "sync the
changes to this file from the working tree to the index, without modifying the
working tree" command. that would make our life so much easier. It would
allow us to remove all filter_and_handle_action code, and any code that
differentiates different inotify events. we would only need to care that *any*
event happened to a certain file, and then tell git to do the right thing
without *any* processing on our part.
No matter how hard we try to tweak the coalescing and scanning the
filesystem after we receive inotify events and so on, there's always the risk
that the working tree is in a different state right when we execute our
commands. executing the wrong git command makes dvcs-autosync wrongfully change
files in your working tree. Now we play on the safe side and prefer 'git add'
over 'git rm' but this fails in cases such as the one described above. And
it's impossible to reliably fix. There will always be race conditions. Also,
all our work to try to come up with the right git command to execute, is only
because git (and other vcs'es) need different commands to copy changes to the
index, depending on what those changes are (deletes vs modifications etc)
well, actually, it seems the latter is untrue. From what I get from
the manpage, "git add --all --update" might be just what I need.
I will experiment a bit with this :)
vcs-home mailing list