Re: [RFC/PATCH 0/7] Rework git core for native submodules

[Jens Lehmann <Jens.Lehmann@web.de>]

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.