On Thu, Feb 18, 2010 at 7:36 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > Ok, this is just a request-for-discussion. I'm trying out a patch like > this, and I think it's a step in the right direction. The git directory > structure is _very_ flat, and currently in a fully built git tree, the > top-level directory has something like 750 files in it. > > After this, it still has a ton of files, but it has shrunk to ~575 files > instead, and at least for my (admittedly somewhat odd) setup, that > actually matters for auto-completion etc. maybe rather than just autocompletion, it does help new code to land in the right place ? I think just for this reason at least it's a good move. I've a wild idea on a new command to add to git and I was pondering between having it as a perl script or a builtin. Now I know where it should go if I choose a builtin, provided you get a wide consensus. > which doesn't seem all that different, but not having that annoying > break in "Display all 180 possibilities?" is quite a relief. > > NOTE! If you do this in a clean tree (no object files etc), or using an > editor that has auto-completion rules that ignores '*.o' files, you > won't see that annoying 'Display all 180 possibilities?' message - it > will just show the choices instead. I think bash has some cut-off > around 100 choices or something. odd. On my msysgit setup and bash 3.1, I get this on a clean tree: $ ls builtin<tab> Display all 90 possibilities? (y or n) But hey, this is on Windows, so we should not bother :-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! -- 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