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

Re: git submodule vs GIT_WORK_TREE

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 26, 2012, 19:51 UTC
Message-ID
<7vobo5c0n0.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4FE9FF0C.8050409@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 17 quoted lines
> Am 26.06.2012 18:07, schrieb Junio C Hamano:
> ...
>> When the user exports GIT_WORK_TREE to tell git that the root of the
>> working tree the user wants to work on resides there (which is
>> needed when the user exports GIT_DIR to tell git that the user wants
>> to work on that repository), that wish obviously applies only to
>> that repository.  If git decides to visit the working tree of a
>> different repository (e.g. a checkout of a submodule bound to the
>> project GIT_WORK_TREE points at), even if it is done in response to
>> the user action (e.g. like passing "--recurse-submodules" option),
>> it should adjust GIT_WORK_TREE and GIT_DIR to be appropriate for
>> operations in the submodule repository while doing so.  If the more
>> recent "recursive" behaviour forgets to do so, it simply is a bug.
>
> I'm not sure what you mean by "appropriate for operations in the
> submodule repository". Should the submodule work tree be searched
> for under $GIT_WORK_TREE of the superproject or under $(pwd)?
I think either
 (1) unset GIT_WORK_TREE/GIT_DIR if the process chdirs to
     $GIT_WORK_TREE/submodule and $GIT_WORK_TREE/submodule/.git is
     the controlling reopsitory of that submodule working tree, or
 (2) set GIT_WORK_TREE/GIT_DIR to point at the working tree and
     repository of the submodule.
would be appropriate.
Show 5 quoted lines
> As far as I can see all submodule code consistently clears all
> environment variables used by git before descending into a
> submodule (at least since February 2010 and 5ce9086dd). Maybe we
> should change that so it sets the GIT_WORK_TREE environment to
> "$GIT_WORK_TREE/submodule" to be consistent?

If the user has to use GIT_WORK_TREE to mark the root level of the superproject working tree as such, it is very likely that the controlling repository of the superproject does not live in the $GIT_WORK_TREE/.git directory (in other words, $GIT_DIR points at somewhere else). Exporting GIT_WORK_TREE/submodule as the new value of GIT_WORK_TREE is sensible, but I do not see a reasonable way to deduce the value of GIT_DIR for the submodule in such a case. The controlling repository of the superproject is located somewhere random; there is no reason to assume the repository for the submodule is somewhere at fixed relation to it.

Does it mean the short answer to Richard's situation is "Don't do it"? I am not sure, but it is starting to sound like it.

Previous: Jens LehmannNext: Jens Lehmann
Message 4 of 13 in “git submodule vs GIT_WORK_TREE”
  1. Richard HartmannJun 26, 2012
  2. Junio C HamanoJun 26, 2012
  3. Jens LehmannJun 26, 2012
  4. Junio C HamanoJun 26, 2012
  5. Jens LehmannJun 26, 2012
  6. Junio C HamanoJun 26, 2012
  7. Richard HartmannJun 29, 2012
  8. Junio C HamanoJun 29, 2012
  9. Junio C HamanoJun 29, 2012
  10. Junio C HamanoJun 29, 2012
  11. Richard HartmannJul 1, 2012
  12. Junio C HamanoJul 2, 2012
  13. Richard HartmannJun 29, 2012

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.