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
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:
top syscalls sorted top syscalls sorted
by acc. ti
16 matches
Mail list logo
