Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> The only thing we show right now are the differences between submodule
> commits and what the superproject has in its index and in its commits.
> Missing are:
>
>   a) modified files
> ...
>   b) new unignored files
>      IMO these files should show up too (the superproject doesn't show
>      ignored files, the submodule state shouldn't do that either). But
>      OTOH i don't see a possibility for loss of data when this state is
>      not shown.

I don't know if we are talking about the same scenario.  What I had in
mind was:

    cd sub
    edit new-file
    tests ok and be happy
    git commit
    cd ..
    git status
    git commit

forgetting that only you have sub/new-file in the world.  It is not loss
of data, but still bad.  Forgetting to add a new-file and committing in a
project without submodule doesn't lose data, but the resulting commit will
be seen as broken by other people.

>   c) a detached HEAD not on any local *or* remote branch
>      This can be fatal when doing a reset, revert or checkout, so it
>      should be shown. Alternatively when applied on a submodule, forcing
>      could be disabled to let the command fail instead of throwing stuff
>      away.

Sorry, I am lost.  Are you worried about "reset/revert/checkout" in the
superproject?  What destructive things do these operations do that you
consider "fatal"?  I am especially puzzled by "revert", as "commit",
"cherry-pick", and "merge" would have the same "fatal" effect as "revert",
but I don't get what "fatality" you are talking about here.

>   d) a detached HEAD not on any remote branch
>      AFAICS this is only important for a push, and could just error out
>      there.

Likewise.

>> I think "clone" has a chicken-and-egg problem.  If all of your project
>> ...
>> what kind of participant you are.  It has to become two-step process;
>> either "clone" going interactive in the middle, or you let the clone to
>> happen and then "submodule init" to express that information.
>
> Yes, we can leave it that way for now (first "clone" and then "submodule
> init <the submodules you need>"). We can migrate to the "group mapping"
> functionality later (which would then allow to force certain submodules
> to always be populated because they appear in every group).

Even with group mapping, you need to clone the superproject first, before
seeing the mapping (which I would assume comes in the superproject).  And
you need to see the mapping to decide what group you belong to.  After
that you can finally drive sub-clone to continue (e.g. I work in the
documentation area, and the group mapping has 'docs' that lets me pull in
submodules for doc/ and common/ directories, without src/ submodule --- I
can only learn that the submodules I am interested in are called 'docs' by
group name or doc/ and common/ subdirectories _after_ I get the clone of
the superproject).

I don't know if "this appears in all groups so let's always sub-clone it"
is very useful in practice, but some sort of mandatory clone/checkout
mechanism would be handy.