git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Beyond inotify recursive watches

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Apr 5, 2013, 16:56 UTC
Message-ID
<CALkWK0ngNM-zrybHOtFGzm5aVnkFMPn1DP0h=2aUf=7b9_sh8A@mail.gmail.com>
In-Reply-To
<20130405155534.GC21852@quack.suse.cz>
Jan Kara wrote:
>   Hum, I have somewhat hard time to understand what do you mean by
> 'magically optimized syscalls'. What should happen in VFS to speedup your
> load?

In retrospect, I think this is a terrible hack to begin with. Tuning the filesystem specifically for git repositories is inelegant on so many levels, I can't recall why I ever thought it would be a good idea. Like all software, Git has scaling issues with ultra-large repositories. Too many stat() calls is just one of the problems: there will be too many objects to do any operation at reasonable speed, and the overall UX would just suck. Instead of growing to a huge monolithic beast that spawns off worker threads for everything and ultimately dying off, I've decided that git should take a different direction: it should work with well with many small easily-composable repositories. I've started work on this already, and it looks very promising.

Let the filesystem people do what they do best: optimizing for all applications uniformly.

Message 1 of 1 in “Re: Beyond inotify recursive watches”
  1. Ramkumar RamachandraApr 5, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.