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
On Mon, Mar 25, 2013 at 5:44 PM, Ramkumar Ramachandra
artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Karsten Blees karsten.bl...@gmail.com 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,
gits...@pobox.com wrote on Wed, 13 Mar 2013 12:38 -0700:
Karsten Blees karsten.bl...@gmail.com 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
On Thu, Mar 14, 2013 at 2:38 AM, Junio C Hamano gits...@pobox.com wrote:
Karsten Blees karsten.bl...@gmail.com 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
Am 13.03.2013 02:03, schrieb Duy Nguyen:
On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees karsten.bl...@gmail.com
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
Karsten Blees karsten.bl...@gmail.com 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
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 Tue, Mar 12, 2013 at 10:43 AM, Ramkumar Ramachandra
artag...@gmail.com 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
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 porting
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 Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees karsten.bl...@gmail.com 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
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 status
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.
15 matches
Mail list logo
