Re: [PATCH 0/6] git-rm absorbs submodule git directory before deletion

From: Stefan Beller <sbeller@google.com>
Date: Dec 13, 2016, 20:09 UTC
Message-ID: <CAGZ79kYM_3NWyRfk42=EshMYVZ=DSWRtn4RU4jkUE7v1EN6ngg@mail.gmail.com>
In-Reply-To: <xmqq60mn3937.fsf@gitster.mtv.corp.google.com>

On Tue, Dec 13, 2016 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> The desired standard for submodules is to have the git dir inside the
>> superprojects git dir (since  501770e, Aug 2011, Move git-dir for
>> submodules), which is why I think an "embedded submodule git dir"
>> is inside the superproject already.
>
> Think how you start a new submodule.  What are the steps you take
> before you say "git submodule add"?  And where does .git for the
> submodule live at that point?

Well there is no way to directly start a submodule (e.g. "git submodule create"), such that there has to be one repo that actually has the git dir inside the working tree.

If the submodule exists already somewhere, there are 2 ways to do it ("git submodule add <URL>" or "git clone && git submodule add") which lead to different outcomes, where the .git resides.

Show 6 quoted lines

> With the current system, you as the submodule originator need to do
> something different to make your working tree of the superproject
> match what the others who clone from your public repository.
>
> And comparing the two layout, the one originally held by the
> submodule originator has .git embedded in the working tree, no?

When starting a new submodule repo, yes, the git dir is inside the working tree.

> All of the above is coming from "submodule" centric mindset.  It
> just is not centric to those who follow what others originated.

ok.

Show 7 quoted lines

> Another reason why I personally see a .git in each submodule working
> tree is "embedded" has nothing to do with Git.  It is an analogy I
> feel (perhaps it is just me) with the word "embedded reporters in
> warzone".  These people are spread around, assigned to units to
> report from places closer to the front line and being closer to the
> leaf of the hierarchy, as opposed to be assigned to a more central
> place like HQ to do their reporting.

I talked to people in the office and got a heavy rejection on the the work "embedded" here for another reason:

    "Does it put the submodule on an embedded device?
    What does embedded even mean?
    The end user is super confused"

So I think we should not use embed or un-embed one way or the other. Instead we need to have another name.

I think absorb is ok-ish, as "git submodule absorb" hints that the superproject absorbs something from the submodule.

So I will reroll it with "absorb" fixing some nits pointed out by David?