On Sun, Feb 10, 2013 at 9:21 PM, Duy Nguyen <[email protected]> wrote:
> On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh <[email protected]>
> wrote:
>> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano <[email protected]> wrote:
>>> Ramkumar Ramachandra <[email protected]> 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.
I think we could do this without interactive communication,
if we did the following:
1) The Daemon waits to see $GIT_DIR/lstat_request, and atomically
writes out $GIT_DIR/lstat_cache. By atomically I mean that it writes
things out to a temporary file, and then does a rename.
2) The client erases $GIT_DIR/lstat_cache, and writes
$GIT_DIR/lstat_request
I think this is better than socket based communication because there
are fewer places to check
for failures.
Robert
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
