Jens Lehmann <Jens.Lehmann@xxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html