Duy Nguyen wrote:
> On Mon, Mar 25, 2013 at 5:44 PM, Ramkumar Ramachandra
> wrote:
>> Just a small heads-up for people using Emacs. 24.4 has inotify
>> support, and magit-inotify.el [1] has already started using it. From
>> initial impressions, I'm quite impressed with it.
>
> Have you tried it?
On Mon, Mar 25, 2013 at 5:44 PM, Ramkumar Ramachandra
wrote:
> Just a small heads-up for people using Emacs. 24.4 has inotify
> support, and magit-inotify.el [1] has already started using it. From
> initial impressions, I'm quite impressed with it.
Have you tried it? From a quick look, it seems
Just a small heads-up for people using Emacs. 24.4 has inotify
support, and magit-inotify.el [1] has already started using it. From
initial impressions, I'm quite impressed with it.
[1]: https://github.com/magit/magit/blob/master/contrib/magit-inotify.el
--
To unsubscribe from this list: send th
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Yes, and you would need one inotify per directory but you do not
>> have an infinite supply of outstanding inotify watch (wasn't the
>> limit like 8k per a single uid or something?), so the daemon must be
>> prepared to say "I'll watch this,
Junio C Hamano writes:
> Karsten Blees writes:
>
>> However, AFAIK inotify doesn't work recursively, so the daemon
>> would at least have to track the directory structure to be able to
>> register / unregister inotify handlers as directories come and go.
>
> Yes, and you would need one inotify p
gits...@pobox.com wrote on Wed, 13 Mar 2013 12:38 -0700:
> Karsten Blees writes:
>
> > However, AFAIK inotify doesn't work recursively, so the daemon
> > would at least have to track the directory structure to be able to
> > register / unregister inotify handlers as directories come and go.
>
>
On Thu, Mar 14, 2013 at 2:38 AM, Junio C Hamano wrote:
> Karsten Blees writes:
>
>> However, AFAIK inotify doesn't work recursively, so the daemon
>> would at least have to track the directory structure to be able to
>> register / unregister inotify handlers as directories come and go.
>
> Yes, a
Karsten Blees writes:
> However, AFAIK inotify doesn't work recursively, so the daemon
> would at least have to track the directory structure to be able to
> register / unregister inotify handlers as directories come and go.
Yes, and you would need one inotify per directory but you do not
have a
Am 13.03.2013 02:03, schrieb Duy Nguyen:
> On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees
> wrote:
>> Hmmm...I don't see how filesystem changes since last invocation can solve
>> the problem, or am I missing something? I think what you mean to say is that
>> the daemon should keep track of the
On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees wrote:
> Hmmm...I don't see how filesystem changes since last invocation can solve the
> problem, or am I missing something? I think what you mean to say is that the
> daemon should keep track of the filesystem *state* of the working copy, or
> alt
Am 10.03.2013 21:17, schrieb Ramkumar Ramachandra:
> git operations are slow on repositories with lots of files, and lots
> of tiny filesystem calls like lstat(), getdents(), open() are
> reposible for this. On the linux-2.6 repository, for instance, the
> numbers for "git status" look like this:
On Tue, Mar 12, 2013 at 03:13:39PM +0530, Ramkumar Ramachandra wrote:
> Heiko Voigt wrote:
> > While talking about platform independence. How about Windows? AFAIK
> > there are no file based sockets. How about using shared memory, thats
> > available, instead? It would greatly reduce the needed po
On Tue, Mar 12, 2013 at 10:43 AM, Ramkumar Ramachandra
wrote:
> Heiko Voigt wrote:
>> While talking about platform independence. How about Windows? AFAIK
>> there are no file based sockets. How about using shared memory, thats
>> available, instead? It would greatly reduce the needed porting effor
Heiko Voigt wrote:
> While talking about platform independence. How about Windows? AFAIK
> there are no file based sockets. How about using shared memory, thats
> available, instead? It would greatly reduce the needed porting effort.
What about the git credential helper: it uses UNIX sockets, no?
On Mon, Mar 11, 2013 at 01:47:03AM +0530, Ramkumar Ramachandra wrote:
> git operations are slow on repositories with lots of files, and lots
> of tiny filesystem calls like lstat(), getdents(), open() are
> reposible for this. On the linux-2.6 repository, for instance, the
> numbers for "git statu
15 matches
Mail list logo
