On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh <robert.allan.zeh@xxxxxxxxx> wrote: > On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: >> >>> This is much better than Junio's suggestion to study possible >>> implementations on all platforms and designing a generic daemon/ >>> communication channel. That's no weekend project. >> >> It appears that you misunderstood what I wrote. That was not "here >> is a design; I want it in my system. Go implemment it". >> >> It was "If somebody wants to discuss it but does not know where to >> begin, doing a small experiment like this and reporting how well it >> worked here may be one way to do so.", nothing more. > > What if instead of communicating over a socket, the daemon > dumped a file containing all of the lstat information after git > wrote a file? By definition the daemon should know about file writes. > > There would be no network communication, which I think would make > things more secure. It would simplify the rendezvous by insisting on > well known locations in $GIT_DIR. We need some sort of interactive communication to the daemon anyway, to validate that the information is uptodate. Assume that a user makes some changes to his worktree before starting the daemon, git needs to know that what the daemon provides does not represent a complete file-change picture and it better refreshes the index the old way once, then trust the daemon. I think we could solve that by storing a "session id", provided by the daemon, in .git/index. If the session id is not present (or does not match what the current daemon gives), refresh the old way. After refreshing, it may ask the daemon for new session id and store it. Next time if the session id is still valid, trust the daemon's data. This session id should be different every time the daemon restarts for this to work. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html