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

Re: [PATCH v4 2/2] push: teach --recurse-submodules the on-demand option

From
Jens Lehmann <jens.lehmann@web.de>
Date
Dec 12, 2011, 22:29 UTC
Message-ID
<4EE6805D.7020708@web.de>
In-Reply-To
<CABURp0okOmsk4JV9Ku5pHJb5vT-kr_fmweNNBKZ_OoRyfZan=Q@mail.gmail.com>
Am 12.12.2011 22:16, schrieb Phil Hord:
Show 15 quoted lines
> On Tue, Oct 18, 2011 at 4:58 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 18.10.2011 00:33, schrieb Junio C Hamano:
>>> We could even declare that the gitlink for such a
>>> submodule should record 0{40} SHA-1 in the superproject, but I do not
>>> think that is necessary.
>>
>> Me neither, e.g. the SHA-1 which was the submodules HEAD when it was added
>> should do nicely. And that would avoid referencing a non-existing commit
>> in case you later want to turn a floating submodule into an exact one.
> 
> 
> I'm sorry I missed this comment before.
> 
> I hope we can allow storing the actual gitlink in the superproject for
> each commit even when we're using floating submodules.

I think you misread my statement, I was just talking about the initial commit containing the newly added submodule, not any subsequent ones. Floating makes differences between the original SHA-1 and the current tip of the branch invisible, so there is nothing to commit.

>  I thought-experimented with this a bit last year and came to the
> conclusion that I should be able to 'float' to tips (developer
> convenience) and also to store the SHA-1 of each gitlink through
> history (automated maybe; as-needed).

Which means that after "git submodule update" floated a submodule branch further, you would have to commit that in the superproject.

> The problem with "float-only" is that it loses history so, for
> example, git-bisect doesn't work.

Yep. And different developers can have the same superproject commit checked out but their submodules can be quite different.

> The problem with "float + gitlinks", of course, is that it looks like
> "not floating" to the developers (git-status is dirty unless
> overridden, etc.)

Yeah. But what if each "git submodule update" would update the tip of the submodule branch and add that to the superproject? You could follow a tip but still produce reproducible trees.

Previous: Phil HordNext: Phil Hord
Message 18 of 20 in “push: submodule support”
  1. 0/2 push: submodule supportFredrik Gustafsson, Aug 19, 2011
  2. 1/2 push: Don't push a repository with unpushed submodulesFredrik Gustafsson, Aug 19, 2011
  3. Junio C HamanoAug 19, 2011
  4. Junio C HamanoAug 20, 2011
  5. Junio C HamanoAug 21, 2011
  6. Heiko VoigtAug 22, 2011
  7. Junio C HamanoAug 22, 2011
  8. Heiko VoigtAug 23, 2011
  9. revision-walking: allow iterating revisions multiple timesHeiko Voigt, Aug 24, 2011
  10. Junio C HamanoAug 24, 2011
  11. 2/2 demonstrate format-callback used in combined diffJunio C Hamano, Aug 20, 2011
  12. Fredrik GustafssonAug 21, 2011
  13. 2/2 push: teach --recurse-submodules the on-demand optionFredrik Gustafsson, Aug 19, 2011
  14. Junio C HamanoSep 2, 2011
  15. Junio C HamanoOct 17, 2011
  16. Jens LehmannOct 18, 2011
  17. Phil HordDec 12, 2011
  18. Jens LehmannDec 12, 2011
  19. Phil HordDec 12, 2011
  20. Jens LehmannDec 13, 2011

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.