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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 5, 2010, 18:31 UTC
Message-ID: <7vd41oz9mp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B43292C.5060106@web.de>

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

Show 11 quoted lines

> 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.

Show 5 quoted lines

>   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.

Show 10 quoted lines

>> 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.