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.
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.
Thanks for your time,
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.
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.
On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann [off-list ref] wrote:
Am 26.01.2011 19:32, schrieb Julian Ibarz:
quoted
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.
quoted
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?
On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann [off-list ref] wrote:
quoted
Am 26.01.2011 19:32, schrieb Julian Ibarz:
quoted
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?
quoted
quoted
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.
On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann [off-list ref] wrote:
quoted
Am 26.01.2011 19:32, schrieb Julian Ibarz:
quoted
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?
In B I have a feature to integrate in master branch. This feature is
in branch old_feature. But this branch is really old. To try this
feature I need to rebuild it at this version. To make the build
success I need also to revert back the submodule C because B is
dependent on it. But finding the good version of C that match
old_feature version is a pain... Is it clear?
quoted
quoted
quoted
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.
Basically my feature would work like this:
in B:
git submodule checkout some_version
This will checkout B but also change A and C so that it is compatible
with some_version of B. Basically it will find the commit in A that
has the closest parent commit of some_version in B. When this is done
it just does git submodule udate on other submodules.
I see in gitk that there is a feature that has a common implementation
for what I want to do:
For every commits you can see Follows and Precedes which lists the
closest label before this release and after. What I need is the same
thing: instead of finding a closest labeled commit, I need to find a
closest commit referenced by A that precedes current HEAD of B. When
this is done I know which commit A has to be and then just have to
call git submodule update in A (update every other submodules except
for B).
Julian
Basically my feature would work like this:
in B:
git submodule checkout some_version
This will checkout B but also change A and C so that it is compatible
with some_version of B. Basically it will find the commit in A that
has the closest parent commit of some_version in B. When this is done
it just does git submodule udate on other submodules.
Thanks, now I understand what you are trying to achieve.
I see in gitk that there is a feature that has a common implementation
for what I want to do:
For every commits you can see Follows and Precedes which lists the
closest label before this release and after. What I need is the same
thing: instead of finding a closest labeled commit, I need to find a
closest commit referenced by A that precedes current HEAD of B. When
this is done I know which commit A has to be and then just have to
call git submodule update in A (update every other submodules except
for B).
I am not aware of something like that in current Git, But I see that
such functionality would be helpful. Care to share your implementation
idea?
Basically my feature would work like this:
in B:
git submodule checkout some_version
This will checkout B but also change A and C so that it is compatible
with some_version of B. Basically it will find the commit in A that
has the closest parent commit of some_version in B. When this is done
it just does git submodule udate on other submodules.
Thanks, now I understand what you are trying to achieve.
quoted
I see in gitk that there is a feature that has a common implementation
for what I want to do:
For every commits you can see Follows and Precedes which lists the
closest label before this release and after. What I need is the same
thing: instead of finding a closest labeled commit, I need to find a
closest commit referenced by A that precedes current HEAD of B. When
this is done I know which commit A has to be and then just have to
call git submodule update in A (update every other submodules except
for B).
I am not aware of something like that in current Git, But I see that
such functionality would be helpful. Care to share your implementation
idea?
Well actually the paragraph just above is what is my implementation
idea. I recognize it is really high level but it is still a start ;).
Basically the "complex" part is to find the precedent commit in B that
is referenced by A. Since gitk has this already but for labels, we
just need to reuse/copy their function that does this but instead as
input having a list of commit labels and find the closest precedent it
is instead the list of commits referenced by A. By the way, anyone
reading this knows where it is in the code of gitk? Or if there is
something like that already in the git code? I never looked into both
code projects.