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

[John Keeping <john@keeping.me.uk>]

On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote:
> Sure, I'll write it out for you from an end-user perspective:

To play Devil's Advocate for a bit...

> 0. Great UI/UX.  No more cd-to-toplevel, and a beautiful set of native
> commands that are consistent with the overall design of git-core.
> Which means: clone (to put something in an unstaged place), add (to
> stage), and commit (to commit the change).  There's now exactly one
> place in your worktree (which is represented as one file in git; think
> of it a sort of symlink)  to look in for all the information.  git
> cat-link <link> to figure out its parameters, git edit-link to edit
> its parameters: no more "find the matching pwd in .gitmodules in
> toplevel".  To remove a submodule, just git rm.  And git mv works!

Presumably now without .git/config support, so I can't override the
checked-in settings without my own custom branch.  Even carrying a dirty
working tree seems problematic here since a checked-out link object is a
directory, which can't have information like the remote URL in it.

> 1. True floating submodules.  You can have a submodule checked out at
> `master` or `v3.1`: no more detached HEADs in submodules unless you
> want fixed submodules.  No additional cruft required to do the
> floating: the information is native, in a link object.

Can't I do that now with "submodule.<name>.branch" and "git submodule
update --remote --rebase" and friends?

> 2. Initializing a nested submodule without having to initialize the
> outer one: no more repo XML nonsense.  And it's composable: you don't
> need to put the information about all submodules in one central place.

How does this interact when there is the following structure:

    super
    `-- sub
        `-- subsub   (specified by sub)

and subsub is specified as a submodule in *both* super and sub but with
different settings.  Do I get different behaviour depending on $PWD?

> 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

> 4. It's suddenly much easier to add new features to this
> implementation.  You don't need to do the kind of gymnastics you'd
> have to do if you were hacking on submodule.c/ git-submodule.sh.
> 
> This is basically how "great design" plays out.