git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Stefan Beller <sbeller@google.com>
Date
Dec 13, 2016, 19:38 UTC
Message-ID
<CAGZ79kYsfybEBnWzv4OjCCLe70fNS=roZdKDbN_DSb4PDVJj7g@mail.gmail.com>
In-Reply-To
<CAGZ79kZCza=cwtzQ7raU3ch_Z_5TDqt0AGN2fPHiRSTDu66Fag@mail.gmail.com>
On Tue, Dec 13, 2016 at 11:13 AM, Stefan Beller <sbeller@google.com> wrote:
Show 25 quoted lines
> On Tue, Dec 13, 2016 at 11:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>>> I do not think there is no dispute about what embedding means.
>>>
>>> double negative: You think we have a slight dispute here.
>>
>> Sorry, I do not think there is any dispute on that.
>>
>>>>  A
>>>> submodule whose .git is inside its working tree has its repository
>>>> embedded.
>>>>
>>>> What we had trouble settling on was what to call the operation to
>>>> undo the embedding, unentangling its repository out of the working
>>>> tree.  I'd still vote for unembed if you want a name to be nominated.
>>>
>>> So I can redo the series with two commands "git submodule [un]embed".
>>>
>>> For me "unembed" == "absorb", such that we could also go with
>>> absorb into superproject <-> embed into worktree
>>
>> With us agreeing that "embed" is about something is _IN_ submodule
>> working tree, unembed would naturally be something becomes OUTSIDE
>> the same thing (i.e. "submodule working tree").

I do not agree, yet. So I thought about this for a while.

The standard in Git is to have the .git directory inside the working tree, which is why you are convinced that embedded means the .git is in the working tree, because you approach this discussion as the Git maintainer, spending only little time on submodule related stuff.

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.

I think both views are legit, and we would want to choose the one that users find most intuitive (and I think there will be users that find either viewpoint intuitive).

So when you have typed "git submodule ", I wonder if a user would assume a submodule-centric mindset of how submodules ought to work or if they still look at a submodule as its own git repo that just happens to be embedded into the superproject.

I guess the latter is the case, so embedding is actually inside the working tree and un-embedding is the relocation to the superproject.

Previous: Stefan BellerNext: Junio C Hamano
Message 17 of 21 in “git-rm absorbs submodule git directory before deletion”
  1. 0/6 git-rm absorbs submodule git directory before deletionStefan Beller, Dec 13, 2016
  2. 2/6 submodule: modernize ok_to_remove_submodule to use argv_arrayStefan Beller, Dec 13, 2016
  3. 4/6 ok_to_remove_submodule: absorb the submodule git dirStefan Beller, Dec 13, 2016
  4. 1/6 submodule.h: add extern keyword to functionsStefan Beller, Dec 13, 2016
  5. 3/6 submodule: add flags to ok_to_remove_submoduleStefan Beller, Dec 13, 2016
  6. 6/6 rm: add absorb a submodules git dir before deletionStefan Beller, Dec 13, 2016
  7. brian m. carlsonDec 13, 2016
  8. Stefan BellerDec 13, 2016
  9. David TurnerDec 13, 2016
  10. 5/6 t3600: slightly modernize styleStefan Beller, Dec 13, 2016
  11. Junio C HamanoDec 13, 2016
  12. Stefan BellerDec 13, 2016
  13. Junio C HamanoDec 13, 2016
  14. Stefan BellerDec 13, 2016
  15. Junio C HamanoDec 13, 2016
  16. Stefan BellerDec 13, 2016
  17. Stefan BellerDec 13, 2016
  18. Junio C HamanoDec 13, 2016
  19. Stefan BellerDec 13, 2016
  20. Stefan BellerDec 13, 2016
  21. Junio C HamanoDec 13, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.