Re: [PATCH 0/6] Initial subproject support (RFC?)

["Alex Riesen" <raa.lkml@gmail.com>]

On 4/10/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Here is, for your enjoyment, the last patch I used to actually test this
> all. I do *not* submit it as a patch for actual inclusion - the other
> patches in the series are, I think, ready to actually be merged. This one
> is not.
>
> It's broken for a few reasons:
>
>  - it allows you to do "git add subproject" to add the subproject to the
>    index (and then use "git commit" to commit it), but even something as
>    simple as "git commit -a" doesn't work right, because the sequence that
>    "git commit -a" uses to update the index doesn't work with the current
>    state of the plumbing (ie the
>
>         git-diff-files --name-only -z |
>                 git-update-index --remove -z --stdin
>
>    thing doesn't work right.
>
>  - even for "git add", the logic isn't really right. It should take the
>    old index state into account to decide if it wants to add it as a
>    subproject.
>

The other thing which will be missed a lot (I miss it that much)
is a subproject-recursive git-commit and git-status.
It is very possible that the default should be different for
the git-commit and git-status: git-commit is likely to have it
off whereas git-status will very much depend on how fast
the usual response is (or wished for). An integrator on very fast
machine may like it on for both, a subproject developer can have
it off for both (to avoid accidental commits and generally being
not interested in anything besides his code), an occasional person
can have the status defaulting to on and commit to off - to avoid
accidental commits in subprojects which are just tracked.

A separate config option and a command-line switch, probably.