Am 07.04.2013 20:21, schrieb John Keeping: > On Sun, Apr 07, 2013 at 11:37:02PM +0530, Ramkumar Ramachandra wrote: >> John Keeping wrote: >>> On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote: >>>> 3. Ability to have very many large submodule repositories without the >>>> performance hit. It makes sense to block stat() from going through >>>> when you have floating submodules. This means that many levels of >>>> nesting are very easily possible. >>> >>> Can't I already control this to some degree? Certainly the following >>> commands take different amounts of time to run: >>> >>> git status >>> git -c status.submodulesummary=true status >> >> You can't control the most fundamental thing, stat(): this is the >> primary killer of performance on a large worktree. There is currently >> no way to block stat(): new-style submodules offers a way to configure >> which submodules to block the stat() on. > > So it would be something like per-submodule --untracked-files and > --ignore-submodules settings? I can see that being useful. Ram is plain wrong here (just like he is on "git rm" and "git mv", even though the latter is currently still in pu). This use case is handled by submodules for years now. Take a look at the "ignore" setting in .gitmodules which give you full control of the stat()s in submodules, in addition you have the repo-wide option diff.ignoreSubmodules. The whole feature list is full of red herrings like this which have nothing to do with the advantages of a new object, but talk about UI issues which are easy to solve in both worlds. -- 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