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

Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository

From
Jens Lehmann <jens.lehmann@web.de>
Date
Jan 26, 2011, 19:39 UTC
Message-ID
<4D407875.7080607@web.de>
In-Reply-To
<AANLkTinMhvBNrBMJ8vQpJdYxP_NgJU2L7JEW0KhXGjhf@mail.gmail.com>
Am 26.01.2011 20:10, schrieb Julian Ibarz:
Show 25 quoted lines
> On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 26.01.2011 19:32, schrieb Julian Ibarz:
>>> I am using git submodule in one of my professional projects and I am
>>> facing an issue when I am using git bisect in one of the submodules.
>>>
>>> Basically I have a meta repository which I will call A and two
>>> submodules B and C. Sometimes I use git bisect in B but it is
>>> dependent on C so when I go back too much in the history of B, C needs
>>> to change its version to a compatible one. Doing this manually is
>>> really time consuming for me and I guess a lot of people have this
>>> issue so I was a little bit surprise to not find easily anything on
>>> the net that permits to do this automatically.
>>
>> What about bisecting in A (doing "git submodule update" after every
>> step) to bisect to a smaller range of commits in B (which are then
>> not dependent on your submodule C anymore and can be bisected inside
>> B)? This of course assumes A properly records the dependencies
>> between B and C.
> 
> Yes but actually my real use case that made me write this mail was
> more I have a feature done in an old branch and to try it I never to
> revert back to this version. In this case, I have to find out the
> corresponding good version in A and C. In this case I cannot start
> like what you propose in A to find out the good version in B and C, I
> already know the version I want in B.

Hmm, looks like I lost you here ... you want to bisect in B although you know what commit you want there? Care to explain a bit more?

Show 10 quoted lines
>>> Is there anything existing to do that and I just didn't find it yet?
>>> If not I think I might have an implementation idea I would like to try
>>> out.
>>
>> The call to "git submodule update" after each bisect step in the
>> superproject will be obsolete as soon as the recursive checkout
>> I am currently working on is done, but that is not here yet.
> 
> Can you be more detailed about your recursive checkout feature? Is it
> what I proposed?

I don't think so, that will just get rid of the extra call to "git submodule update" when bisecting in A.

Previous: Julian IbarzNext: Julian Ibarz
Message 4 of 20 in “Updating a submodule with a compatible version from another submodule version using the parent meta-repository”
  1. Julian IbarzJan 26, 2011
  2. Jens LehmannJan 26, 2011
  3. Julian IbarzJan 26, 2011
  4. Jens LehmannJan 26, 2011
  5. Julian IbarzJan 26, 2011
  6. Jens LehmannJan 26, 2011
  7. Julian IbarzJan 26, 2011
  8. Junio C HamanoJan 26, 2011
  9. Julian IbarzJan 26, 2011
  10. Junio C HamanoJan 26, 2011
  11. Heiko VoigtJan 29, 2011
  12. Julian IbarzJan 30, 2011
  13. Julian IbarzFeb 3, 2011
  14. Heiko VoigtFeb 6, 2011
  15. Heiko VoigtFeb 9, 2011
  16. Julian IbarzFeb 12, 2011
  17. Heiko VoigtFeb 13, 2011
  18. Julian IbarzFeb 13, 2011
  19. Heiko VoigtFeb 14, 2011
  20. Julian IbarzFeb 20, 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.