git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Julian Ibarz <julian.ibarz@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
Date: Wed, 26 Jan 2011 20:39:33 +0100	[thread overview]
Message-ID: <4D407875.7080607@web.de> (raw)
In-Reply-To: <AANLkTinMhvBNrBMJ8vQpJdYxP_NgJU2L7JEW0KhXGjhf@mail.gmail.com>

Am 26.01.2011 20:10, schrieb Julian Ibarz:
> 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?

>>> 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.

  reply	other threads:[~2011-01-26 19:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTinN1XVsAZXGLqkuhysrJ8-TCtGm4pOu2RfCEVVp@mail.gmail.com>
2011-01-26 18:32 ` Updating a submodule with a compatible version from another submodule version using the parent meta-repository Julian Ibarz
2011-01-26 19:06   ` Jens Lehmann
2011-01-26 19:10     ` Julian Ibarz
2011-01-26 19:39       ` Jens Lehmann [this message]
2011-01-26 19:48         ` Julian Ibarz
2011-01-26 20:31           ` Jens Lehmann
2011-01-26 20:43             ` Julian Ibarz
2011-01-26 20:41           ` Junio C Hamano
2011-01-26 20:45             ` Julian Ibarz
2011-01-26 22:05               ` Junio C Hamano
2011-01-29 11:08                 ` Heiko Voigt
2011-01-30  9:44                   ` Julian Ibarz
2011-02-03  4:31                     ` Julian Ibarz
2011-02-06 18:51                       ` Heiko Voigt
2011-02-09 19:36                       ` Heiko Voigt
2011-02-12 20:32                         ` Julian Ibarz
2011-02-13 13:30                           ` Heiko Voigt
2011-02-13 18:59                             ` Julian Ibarz
2011-02-14 21:13                               ` Heiko Voigt
2011-02-20  1:15                                 ` Julian Ibarz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D407875.7080607@web.de \
    --to=jens.lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=julian.ibarz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).