On Fri, Mar 18, 2016 at 2:14 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Duy, > > On Fri, 18 Mar 2016, Duy Nguyen wrote: > >> On Thu, Mar 17, 2016 at 9:43 PM, Johannes Schindelin >> <Johannes.Schindelin@xxxxxx> wrote: >> >> > I know of use cases where the index weighs 300MB, and falling back to >> > reading it directly *really* hurts. >> >> For crying out loud, what do you store in that repo? What I have in >> mind for all these works are indexes in 10MB range, or maybe 50MB max. > > Welcome to the real world. > >> Very unscientifically, git.git index is about 274kb and contains ~3000 >> entries, so 94 bytes per entry on average. > > In terms of software projects' size, git.git is but a toy. Most developers > deal with vastly larger (and often messier) repositories. This is > especially true outside Open Source. Even the Linux kernel's repository is > *tiny* compared to real-world repositories. > > I am sure that David could tell many a tale about repository/working > directory size, too. I know a few real-world repos, decades old, but I don't remember if any of them reached this size. Did I get that 3 million entry number right? Because even my whole /home uses over 1m inodes. And whole /usr only has 300k files. If the number of entries is lower, maybe there's some improvement we can do to reduce index size a bit. There's some fast compression we can do, for starter. > So yeah, this is the challenge: to make Git work at real-world scale > (didn't we hear a lot about this at the latest Git Merge?) I'm all for making Junio cry by using Git for what it is (or was) not intended for, but this seems too much. A repo about 500k files or less, I think I can deal with, not those in million range. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html