* Updating a submodule with a compatible version from another submodule version using the parent meta-repository [not found] <AANLkTinN1XVsAZXGLqkuhysrJ8-TCtGm4pOu2RfCEVVp@mail.gmail.com> @ 2011-01-26 18:32 ` Julian Ibarz 2011-01-26 19:06 ` Jens Lehmann 0 siblings, 1 reply; 20+ messages in thread From: Julian Ibarz @ 2011-01-26 18:32 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 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 0 siblings, 1 reply; 20+ messages in thread From: Jens Lehmann @ 2011-01-26 19:06 UTC (permalink / raw) To: Julian Ibarz; +Cc: git 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. > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 19:06 ` Jens Lehmann @ 2011-01-26 19:10 ` Julian Ibarz 2011-01-26 19:39 ` Jens Lehmann 0 siblings, 1 reply; 20+ messages in thread From: Julian Ibarz @ 2011-01-26 19:10 UTC (permalink / raw) To: Jens Lehmann; +Cc: git 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. >> 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 19:10 ` Julian Ibarz @ 2011-01-26 19:39 ` Jens Lehmann 2011-01-26 19:48 ` Julian Ibarz 0 siblings, 1 reply; 20+ messages in thread From: Jens Lehmann @ 2011-01-26 19:39 UTC (permalink / raw) To: Julian Ibarz; +Cc: git 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 19:39 ` Jens Lehmann @ 2011-01-26 19:48 ` Julian Ibarz 2011-01-26 20:31 ` Jens Lehmann 2011-01-26 20:41 ` Junio C Hamano 0 siblings, 2 replies; 20+ messages in thread From: Julian Ibarz @ 2011-01-26 19:48 UTC (permalink / raw) To: Jens Lehmann; +Cc: git > 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? 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? >>>> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 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 1 sibling, 1 reply; 20+ messages in thread From: Jens Lehmann @ 2011-01-26 20:31 UTC (permalink / raw) To: Julian Ibarz; +Cc: git Am 26.01.2011 20:48, schrieb Julian Ibarz: > 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 20:31 ` Jens Lehmann @ 2011-01-26 20:43 ` Julian Ibarz 0 siblings, 0 replies; 20+ messages in thread From: Julian Ibarz @ 2011-01-26 20:43 UTC (permalink / raw) To: Jens Lehmann; +Cc: git > Am 26.01.2011 20:48, schrieb Julian Ibarz: >> 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? 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 19:48 ` Julian Ibarz 2011-01-26 20:31 ` Jens Lehmann @ 2011-01-26 20:41 ` Junio C Hamano 2011-01-26 20:45 ` Julian Ibarz 1 sibling, 1 reply; 20+ messages in thread From: Junio C Hamano @ 2011-01-26 20:41 UTC (permalink / raw) To: Julian Ibarz; +Cc: Jens Lehmann, git Julian Ibarz <julian.ibarz@gmail.com> writes: >> 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? That sounds like bisecting in C with a frozen checkout of B to see which version in C works well with that target commit in B you know you want to use. Why do you need to bisect in B??? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 20:41 ` Junio C Hamano @ 2011-01-26 20:45 ` Julian Ibarz 2011-01-26 22:05 ` Junio C Hamano 0 siblings, 1 reply; 20+ messages in thread From: Julian Ibarz @ 2011-01-26 20:45 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jens Lehmann, git On Wed, Jan 26, 2011 at 3:41 PM, Junio C Hamano <gitster@pobox.com> wrote: > Julian Ibarz <julian.ibarz@gmail.com> writes: > >>> 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? > > That sounds like bisecting in C with a frozen checkout of B to see which > version in C works well with that target commit in B you know you want to > use. Why do you need to bisect in B??? > Forget about bisect. This is a different use case where I need the feature I am talking about: checkout an old version in B and automatically having A and C switch to a compatible version (the cause can be because of a bisect or just because I want to try an old feature not yet integrated into master or whatever the reason I want to be on this old version). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 20:45 ` Julian Ibarz @ 2011-01-26 22:05 ` Junio C Hamano 2011-01-29 11:08 ` Heiko Voigt 0 siblings, 1 reply; 20+ messages in thread From: Junio C Hamano @ 2011-01-26 22:05 UTC (permalink / raw) To: Julian Ibarz; +Cc: Jens Lehmann, git Julian Ibarz <julian.ibarz@gmail.com> writes: > On Wed, Jan 26, 2011 at 3:41 PM, Junio C Hamano <gitster@pobox.com> wrote: >> Julian Ibarz <julian.ibarz@gmail.com> writes: >> >>>> 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? >> >> That sounds like bisecting in C with a frozen checkout of B to see which >> version in C works well with that target commit in B you know you want to >> use. Why do you need to bisect in B??? > > Forget about bisect. This is a different use case where I need the > feature I am talking about: checkout an old version in B and > automatically having A and C switch to a compatible version (the cause > can be because of a bisect or just because I want to try an old > feature not yet integrated into master or whatever the reason I want > to be on this old version). If that version of submodule B is explicitly bound to a commit in the superproject A, you know which version of A and C were recorded, and the problem is solved. But otherwise, you are wishing for a miracle, I am afraid, without giving your tool (git or your own tool you write on top of it) some hint to say how "similar" commits in B are, as there is no guarantee that anybody even tried a commit that is not directly referenced from the superproject together with other parts of the system. If you are confident that you didn't introduce different kind of dependency to other submodules while developing your "old_feature" branch in submodule B, one strategy may be to find an ancestor, preferrably the fork point, of your "old_feature" branch that is bound to the superproject A. Then at that point at least you know whoever made that commit in A tested the combination of what was recorded in that commit, together with the version of B and C, and you can go forward from there, replaying the changes you made to the "old_feature" branch in submodule B. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-26 22:05 ` Junio C Hamano @ 2011-01-29 11:08 ` Heiko Voigt 2011-01-30 9:44 ` Julian Ibarz 0 siblings, 1 reply; 20+ messages in thread From: Heiko Voigt @ 2011-01-29 11:08 UTC (permalink / raw) To: Junio C Hamano; +Cc: Julian Ibarz, Jens Lehmann, git Hi, On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote: > If that version of submodule B is explicitly bound to a commit in the > superproject A, you know which version of A and C were recorded, and the > problem is solved. > [...] > > If you are confident that you didn't introduce different kind of > dependency to other submodules while developing your "old_feature" branch > in submodule B, one strategy may be to find an ancestor, preferrably the > fork point, of your "old_feature" branch that is bound to the superproject > A. Then at that point at least you know whoever made that commit in A > tested the combination of what was recorded in that commit, together with > the version of B and C, and you can go forward from there, replaying the > changes you made to the "old_feature" branch in submodule B. Lets extend your explanation a little further and maybe demonstrate the problem Julian is having a little more. I think what Julian searches for is a tool in git that does the lookup for you which is AFAIK not that easy currently. It seems to be a quite useful feature. Here what I understand Julian wants: 1. Find the most recent superproject commit X'' in A that records a submodule commit X' in B which contains the commit X in B you are searching for. For this we would need use something similar to git describe --contains but instead of using the list of existing tags in B it should use the list of commits in B which are recorded in A. Here a drawing to explain (linear history for simplicity): superproject A: O---O---X''---O \ submodule B: \ \ O---X---O---X'---O---O 2. Look up the commit of C which is recorded in X'' of A and check it out. Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline. Is there already anything that implements git describe --contains for a defined list of commits instead of refs? Cheers Heiko ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-01-29 11:08 ` Heiko Voigt @ 2011-01-30 9:44 ` Julian Ibarz 2011-02-03 4:31 ` Julian Ibarz 0 siblings, 1 reply; 20+ messages in thread From: Julian Ibarz @ 2011-01-30 9:44 UTC (permalink / raw) To: Heiko Voigt; +Cc: Junio C Hamano, Jens Lehmann, git Today I have started to implement a proof of concept in C (I know a script would be better but I am really not good in sh so...). I struggle with the manipulation of the git API. I have pushed my work here: http://gitorious.org/julian_ibarz_git/julian_ibarz_git in branch submodule_checkout My work is in: builtin/submodulecheckout.c And my questions are prepended by the keyword QUESTION (two questions for now only). Any help is welcome. Thanks, Julian Ibarz On Sat, Jan 29, 2011 at 6:08 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote: > Hi, > > On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote: >> If that version of submodule B is explicitly bound to a commit in the >> superproject A, you know which version of A and C were recorded, and the >> problem is solved. >> > [...] >> >> If you are confident that you didn't introduce different kind of >> dependency to other submodules while developing your "old_feature" branch >> in submodule B, one strategy may be to find an ancestor, preferrably the >> fork point, of your "old_feature" branch that is bound to the superproject >> A. Then at that point at least you know whoever made that commit in A >> tested the combination of what was recorded in that commit, together with >> the version of B and C, and you can go forward from there, replaying the >> changes you made to the "old_feature" branch in submodule B. > > Lets extend your explanation a little further and maybe demonstrate the problem > Julian is having a little more. I think what Julian searches for is a tool in > git that does the lookup for you which is AFAIK not that easy currently. It > seems to be a quite useful feature. Here what I understand Julian wants: > > 1. Find the most recent superproject commit X'' in A that records a submodule > commit X' in B which contains the commit X in B you are searching for. > > For this we would need use something similar to git describe --contains > but instead of using the list of existing tags in B it should use the list > of commits in B which are recorded in A. > > Here a drawing to explain (linear history for simplicity): > > superproject A: > > O---O---X''---O > \ > submodule B: \ > \ > O---X---O---X'---O---O > > 2. Look up the commit of C which is recorded in X'' of A and check it > out. > > Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline. > Is there already anything that implements git describe --contains for a defined > list of commits instead of refs? > > Cheers Heiko > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 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 0 siblings, 2 replies; 20+ messages in thread From: Julian Ibarz @ 2011-02-03 4:31 UTC (permalink / raw) To: Heiko Voigt; +Cc: Junio C Hamano, Jens Lehmann, git Hi, After a couple of hours, I have finally succeeded to go through the entire history of a repository and I can detect the submodules in a tree of a commit. For those interested here is the source code: http://gitorious.org/julian_ibarz_git/julian_ibarz_git/blobs/submodule_checkout/builtin/submodulecheckout.c Next time I will build the list of commits of a submodule in the entire history. Then I will need to find the distance of each commit in the list compared to the current commit of a submodule and keep the closest one (which has to be a parent so an algebric distance would be good to have). So now my two questions that could save me some time are: - is there a function that gives the distance between two commits? I'm sure there is something like this coded somewhere but I didn't find it yet - is the struct decorate a hash map and if yes could someone explain me how to use it or point me to a location where it is used? Except from that I think I have all the information I need. Best regards, Julian Ibarz On Sun, Jan 30, 2011 at 4:44 AM, Julian Ibarz <julian.ibarz@gmail.com> wrote: > Today I have started to implement a proof of concept in C (I know a > script would be better but I am really not good in sh so...). I > struggle with the manipulation of the git API. I have pushed my work > here: > > http://gitorious.org/julian_ibarz_git/julian_ibarz_git > > in branch submodule_checkout > > My work is in: > > builtin/submodulecheckout.c > > And my questions are prepended by the keyword QUESTION (two questions > for now only). > > Any help is welcome. > > Thanks, > > Julian Ibarz > > On Sat, Jan 29, 2011 at 6:08 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote: >> Hi, >> >> On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote: >>> If that version of submodule B is explicitly bound to a commit in the >>> superproject A, you know which version of A and C were recorded, and the >>> problem is solved. >>> >> [...] >>> >>> If you are confident that you didn't introduce different kind of >>> dependency to other submodules while developing your "old_feature" branch >>> in submodule B, one strategy may be to find an ancestor, preferrably the >>> fork point, of your "old_feature" branch that is bound to the superproject >>> A. Then at that point at least you know whoever made that commit in A >>> tested the combination of what was recorded in that commit, together with >>> the version of B and C, and you can go forward from there, replaying the >>> changes you made to the "old_feature" branch in submodule B. >> >> Lets extend your explanation a little further and maybe demonstrate the problem >> Julian is having a little more. I think what Julian searches for is a tool in >> git that does the lookup for you which is AFAIK not that easy currently. It >> seems to be a quite useful feature. Here what I understand Julian wants: >> >> 1. Find the most recent superproject commit X'' in A that records a submodule >> commit X' in B which contains the commit X in B you are searching for. >> >> For this we would need use something similar to git describe --contains >> but instead of using the list of existing tags in B it should use the list >> of commits in B which are recorded in A. >> >> Here a drawing to explain (linear history for simplicity): >> >> superproject A: >> >> O---O---X''---O >> \ >> submodule B: \ >> \ >> O---X---O---X'---O---O >> >> 2. Look up the commit of C which is recorded in X'' of A and check it >> out. >> >> Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline. >> Is there already anything that implements git describe --contains for a defined >> list of commits instead of refs? >> >> Cheers Heiko >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-02-03 4:31 ` Julian Ibarz @ 2011-02-06 18:51 ` Heiko Voigt 2011-02-09 19:36 ` Heiko Voigt 1 sibling, 0 replies; 20+ messages in thread From: Heiko Voigt @ 2011-02-06 18:51 UTC (permalink / raw) To: Julian Ibarz; +Cc: Junio C Hamano, Jens Lehmann, git Hi Julian, interesting work so far. One thing regarding the mailing list: Please do not top post and try to cut non relevant text (the one you are not replying to) from your replies. On Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote: > After a couple of hours, I have finally succeeded to go through the > entire history of a repository and I can detect the submodules in a > tree of a commit. For those interested here is the source code: > > http://gitorious.org/julian_ibarz_git/julian_ibarz_git/blobs/submodule_checkout/builtin/submodulecheckout.c > > Next time I will build the list of commits of a submodule in the > entire history. Sounds great. That will be one tool you need. Here is a small script snippet which already does that as an example for the msysgit repository (git://repo.or.cz/msysgit.git): export sub=git git log --pretty="%h" -- $sub | \ while read i; do git ls-tree $i -- $sub; done | \ cut -f3 -d" " | cut -f1 It outputs all the hashes that have been registered for the git submodule. Maybe thats a good starting point to find example code in C. You can use it for other submodules also just change the name in the variable sub. > Then I will need to find the distance of each commit > in the list compared to the current commit of a submodule and keep > the closest one (which has to be a parent so an algebric distance > would be good to have). Have a look at the codepath that is used for git branch --contains <sha1> It essentially does the thing you want (find all refs that contain a commit). An approach could be to extend this mechanism not to iterate through all refs but e.g. take a list of sha1's for iteration. > So now my two questions that could save me some time are: > - is there a function that gives the distance between two commits? I'm > sure there is something like this coded somewhere but I didn't find it > yet > - is the struct decorate a hash map and if yes could someone explain > me how to use it or point me to a location where it is used? Please see the tips above. > Except from that I think I have all the information I need. There are a few points I would like to mention: * Citing my drawing: > >> superproject A: > >> > >> O---O---X''---O > >> \ > >> submodule B: \ > >> \ > >> O---X---O---X'---O---O There can be multiple X' which contain X. These are all valid candidates. The same applies to X'' where there can be multiple candidates that record a specific X'. IMO, all of them need to be considered. If in the end they all reduce to one commit in submodule C you can check that out. If not printing a list of all candidates is probably the best option. * If we want your code to go upstream it probably needs to be integrated as a subcommand into the current submodule script. I can offer to help you on the bash scripting side. I think once the tools to find the appropriate commits are ready that will not be a big issue. * I think for protoyping the tools you can later use in the submodule script its fine to implement your own command. Keep in mind that you later on you should probably integrate your code into the appropriate existing commands. Here some suggestions. To support proper bash scripting two parts come into my mind: 1. A tool to output all of the submodules commits which are candidates for X'' like the script snippet above. 2. A tool that takes the list from 1. and then reduces that list to a list of commits that actually register the possible commits X'. If that is one commit X'' we can directly checkout. If not we print the list in a nice format and let the user choose. Looking forward to your work. Cheers Heiko ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 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 1 sibling, 1 reply; 20+ messages in thread From: Heiko Voigt @ 2011-02-09 19:36 UTC (permalink / raw) To: Julian Ibarz; +Cc: Junio C Hamano, Jens Lehmann, git Hi Julian, On Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote: > So now my two questions that could save me some time are: > - is there a function that gives the distance between two commits? I'm > sure there is something like this coded somewhere but I didn't find it > yet One thing which now came to my mind is that you might be interested in is to use merge bases to find the earliest commit that contains a certain revision. Have a look at how I implemented the submodule merge strategy that might help you. You can find it in commit 68d03e4a. I basically do a search for the earliest commit that contains the commits from both sides. You could use a similar strategy but limit the possible candidates to a restricted list of commits which are contained in the supermodule. Cheers Heiko ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-02-09 19:36 ` Heiko Voigt @ 2011-02-12 20:32 ` Julian Ibarz 2011-02-13 13:30 ` Heiko Voigt 0 siblings, 1 reply; 20+ messages in thread From: Julian Ibarz @ 2011-02-12 20:32 UTC (permalink / raw) To: Heiko Voigt; +Cc: Junio C Hamano, Jens Lehmann, git Hi Heiko, Thanks for all your feedbacks. Before your first mail I had already implemented command 1 you are talking about and almost finished command 2. Today I could spend some time again on this side project and I have finished command 2. Here is what you do: git submodulecheckout --find-versions <submodule> > <some_temp_file> cd <submodule> git submodulecheckout --find-closest < <some_temp_file> This will output the version you need to checkout in the meta repository. I don't handle the case where there is multiple solutions but it is a good start I think. I think with this you can already start the integration in the submodule bash script to make it recursive and be more user-friendly? Are you still interested Heiko? I have pushed this to my repository so you can check it out if you want. Both commands have a suboptimal implementation but it can be improved without changing the current API so I think it is a minor issue. I will probably try this at work today on msysgit. Currently I am doing this at home on my linux using some open source meta-repository, if you have a big one to try this feature let me know (I am currently using git://git.assembla.com/luadocsuperforest.git and it is not that big). Best regards, Julian Ibarz On Wed, Feb 9, 2011 at 2:36 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote: > Hi Julian, > > On Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote: >> So now my two questions that could save me some time are: >> - is there a function that gives the distance between two commits? I'm >> sure there is something like this coded somewhere but I didn't find it >> yet > > One thing which now came to my mind is that you might be interested in > is to use merge bases to find the earliest commit that contains a > certain revision. > > Have a look at how I implemented the submodule merge strategy that might > help you. You can find it in commit 68d03e4a. I basically do a search > for the earliest commit that contains the commits from both sides. You > could use a similar strategy but limit the possible candidates to a > restricted list of commits which are contained in the supermodule. > > Cheers Heiko > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-02-12 20:32 ` Julian Ibarz @ 2011-02-13 13:30 ` Heiko Voigt 2011-02-13 18:59 ` Julian Ibarz 0 siblings, 1 reply; 20+ messages in thread From: Heiko Voigt @ 2011-02-13 13:30 UTC (permalink / raw) To: Julian Ibarz; +Cc: Junio C Hamano, Jens Lehmann, git Hi Julian, On Sat, Feb 12, 2011 at 03:32:43PM -0500, Julian Ibarz wrote: > Thanks for all your feedbacks. Before your first mail I had already > implemented command 1 you are talking about and almost finished > command 2. Today I could spend some time again on this side project > and I have finished command 2. Here is what you do: > > git submodulecheckout --find-versions <submodule> > <some_temp_file> > cd <submodule> > git submodulecheckout --find-closest < <some_temp_file> I do not quite understand how this is used. I just tried it on the msysgit repository. Which is a good candidate for testing since you can easily verify the results because for each git version there is a corresponding tag in the superproject. You can find it on repo: http://repo.or.cz/w/msysgit.git As far as I understand the sha1 you are searching for is determined by the currently checked out revision. So here we go: cd msysgit/git git checkout v1.7.2.3.msysgit.0~3 cd .. git submodulecheckout --find-versions git > git-versions.txt cd git git submodulecheckout --find-closest < ../git-versions.txt > submodulecheckout: no commit found Ok lets not be so hard: git checkout v1.7.2.3.msysgit.0 cd .. git submodulecheckout --find-versions git > git-versions.txt cd git git submodulecheckout --find-closest < ../git-versions.txt > 820fd48475eb72cdd4f2 Close but not quite the right commit. See the output of git log: 820fd48 Chomp CRLF before feeding to tar when building netinstaller. 83e164c Avoid quoting environment variable values. daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3 Whats strange is that this commit did not even change the submodule. I think currently it does not make sense to implement the scripting since the interface is not yet cleaned up enough. It should be possible to specify a commit as parameter and the path should probably go after that like the other commands do as well. The other issue is that we need to change the working directory. IMO, everything should be possible to do from superproject. Have a look at add_submodule_odb() in submodule.c it lets you load the database of a submodule. This way you can run the --find-closest from the superproject. So what I would be looking for is something like this: # This looks up all commits of <submodule> ever registered in this # project git submodulecheckout --find-versions <submodule> > out.tmp # This reads the previous list and outputs a list of of all the commits # that contain <treeish>. Function in_merge_bases(treeish, i&commit, 1) # can be of help here. Afterwards you have to prune all later commits # that contain earlier ones. I did this in find_first_merges(). I # suggest to refactor that code into a function so that you can use it. git submodulecheckout --find-closest <treeish> -- <submodule> < out.tmp > out2.tmp # And now we can search for the commit in the other submodule C git submodulecheckout --list-commits <other submodule> < out2.tmp > out3.tmp And if out3.tmp just contained one line we could checkout that one. I am still not sure in which command these options could go. Junio do you maybe have a suggestion? Since its all about submodules it would make sense to put it in 'git submodule' but thats already the script. Maybe a new 'git-submodule-tool' ? I suggest that you start implementing some basic tests if you found the right commits using the testsuite. Basically you build up a sample repository where you know which commits of the submodules are tied together with a sequence of commands. Then you check whether your commands find the correct one. Maybe have a look at the submodule tests Jens is implementing on his branch: https://github.com/jlehmann/git-submod-enhancements Hope that helps. Cheers Heiko ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-02-13 13:30 ` Heiko Voigt @ 2011-02-13 18:59 ` Julian Ibarz 2011-02-14 21:13 ` Heiko Voigt 0 siblings, 1 reply; 20+ messages in thread From: Julian Ibarz @ 2011-02-13 18:59 UTC (permalink / raw) To: Heiko Voigt; +Cc: Junio C Hamano, Jens Lehmann, git On Sun, Feb 13, 2011 at 8:30 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote: > Hi Julian, > > On Sat, Feb 12, 2011 at 03:32:43PM -0500, Julian Ibarz wrote: >> Thanks for all your feedbacks. Before your first mail I had already >> implemented command 1 you are talking about and almost finished >> command 2. Today I could spend some time again on this side project >> and I have finished command 2. Here is what you do: >> >> git submodulecheckout --find-versions <submodule> > <some_temp_file> >> cd <submodule> >> git submodulecheckout --find-closest < <some_temp_file> > > I do not quite understand how this is used. I just tried it on the > msysgit repository. Which is a good candidate for testing since you can > easily verify the results because for each git version there is a > corresponding tag in the superproject. > > You can find it on repo: http://repo.or.cz/w/msysgit.git > > As far as I understand the sha1 you are searching for is determined by > the currently checked out revision. So here we go: > > cd msysgit/git > git checkout v1.7.2.3.msysgit.0~3 > cd .. > git submodulecheckout --find-versions git > git-versions.txt > cd git > git submodulecheckout --find-closest < ../git-versions.txt >> submodulecheckout: no commit found There was multiple bugs in the version you tried and I just pushed the fix. It is working on my repository at work but on msysgit, just forget it, it is too slow. I still need to optimize it, it doesn't scale at all lol. But it shouldn't be a problem. The two optimizations I want to do: * use a real hash map to know if I already visited a commit * go through the history only once and finding the closest commit in a list instead of going through the entire history for each commit of the least I also need to send the list of possible commits in the meta-repository instead of the first one. For msysgit sometime some solutions have more than 20 possible solutions! > Ok lets not be so hard: > > git checkout v1.7.2.3.msysgit.0 > cd .. > git submodulecheckout --find-versions git > git-versions.txt > cd git > git submodulecheckout --find-closest < ../git-versions.txt >> 820fd48475eb72cdd4f2 > > Close but not quite the right commit. See the output of git log: > 820fd48 Chomp CRLF before feeding to tar when building netinstaller. > 83e164c Avoid quoting environment variable values. > daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3 > > Whats strange is that this commit did not even change the submodule. Well because it is _exactly_ the commit that point to the current submodule version you have checked out :) So it _is_ the good version. Which version were you thinking was good? > I think currently it does not make sense to implement the scripting > since the interface is not yet cleaned up enough. It should be possible > to specify a commit as parameter and the path should probably go after > that like the other commands do as well. > > The other issue is that we need to change the working directory. IMO, > everything should be possible to do from superproject. Have a look at > add_submodule_odb() in submodule.c it lets you load the database of a > submodule. This way you can run the --find-closest from the superproject. I don't think we want to do that. The usual scenario is: * you are in a submodule * you checkout a specific version * you want the meta-repo and side submodules to be updated accordingly And in this scenario at the beginning you are at the submodule directory, not the meta repository so... What do you think? Also even if in these low-level commands you need to change directory, if it is hided in an integration in the sh submodule script, it doesn't matter right? > So what I would be looking for is something like this: > > # This looks up all commits of <submodule> ever registered in this > # project > git submodulecheckout --find-versions <submodule> > out.tmp > > # This reads the previous list and outputs a list of of all the commits > # that contain <treeish>. Function in_merge_bases(treeish, i&commit, 1) > # can be of help here. Afterwards you have to prune all later commits > # that contain earlier ones. I did this in find_first_merges(). I > # suggest to refactor that code into a function so that you can use it. > git submodulecheckout --find-closest <treeish> -- <submodule> < out.tmp > out2.tmp > > # And now we can search for the commit in the other submodule C > git submodulecheckout --list-commits <other submodule> < out2.tmp > out3.tmp > > And if out3.tmp just contained one line we could checkout that one. I am > still not sure in which command these options could go. Junio do you > maybe have a suggestion? Since its all about submodules it would make > sense to put it in 'git submodule' but thats already the script. > > Maybe a new 'git-submodule-tool' ? Before I wanted to name it submodule-checkout but I think I hade a naming conflict issue with submodule... not sure if submodule-tool will work... > I suggest that you start implementing some basic tests if you found the > right commits using the testsuite. Basically you build up a sample > repository where you know which commits of the submodules are tied > together with a sequence of commands. Then you check whether your > commands find the correct one. Maybe have a look at the submodule > tests Jens is implementing on his branch: > > https://github.com/jlehmann/git-submod-enhancements I will take a look into this. Thanks, Julian > Hope that helps. > > Cheers Heiko > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-02-13 18:59 ` Julian Ibarz @ 2011-02-14 21:13 ` Heiko Voigt 2011-02-20 1:15 ` Julian Ibarz 0 siblings, 1 reply; 20+ messages in thread From: Heiko Voigt @ 2011-02-14 21:13 UTC (permalink / raw) To: Julian Ibarz; +Cc: Junio C Hamano, Jens Lehmann, git Hi, On Sun, Feb 13, 2011 at 01:59:09PM -0500, Julian Ibarz wrote: > On Sun, Feb 13, 2011 at 8:30 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote: > > Ok lets not be so hard: > > > > git checkout v1.7.2.3.msysgit.0 > > cd .. > > git submodulecheckout --find-versions git > git-versions.txt > > cd git > > git submodulecheckout --find-closest < ../git-versions.txt > >> 820fd48475eb72cdd4f2 > > > > Close but not quite the right commit. See the output of git log: > > 820fd48 Chomp CRLF before feeding to tar when building netinstaller. > > 83e164c Avoid quoting environment variable values. > > daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3 > > > > Whats strange is that this commit did not even change the submodule. > > Well because it is _exactly_ the commit that point to the current > submodule version you have checked out :) So it _is_ the good version. > Which version were you thinking was good? Well I think the interface was/is still confusing me. Once you change to one where I can specify the hash I want to search for I will give it another try. > > I think currently it does not make sense to implement the scripting > > since the interface is not yet cleaned up enough. It should be possible > > to specify a commit as parameter and the path should probably go after > > that like the other commands do as well. > > > > The other issue is that we need to change the working directory. IMO, > > everything should be possible to do from superproject. Have a look at > > add_submodule_odb() in submodule.c it lets you load the database of a > > submodule. This way you can run the --find-closest from the superproject. > > I don't think we want to do that. The usual scenario is: > > * you are in a submodule > * you checkout a specific version > * you want the meta-repo and side submodules to be updated accordingly > > And in this scenario at the beginning you are at the submodule > directory, not the meta repository so... What do you think? Also even > if in these low-level commands you need to change directory, if it is > hided in an integration in the sh submodule script, it doesn't matter > right? Well I think the interface should be useable by hand also. Lots of tools in git were invented by plugging the tools together differently than the original developer even had in his mind. So a nice "do only one thing but that very good" kind of interface makes sense. I think a nice thing would be if you could stay in one directory and it should not be too hard since we have add_submodule_odb(). Implementation would be easier if we started this command from the supermodule since searching for a supermodule from a submodule is still missing. > > So what I would be looking for is something like this: > > > > # This looks up all commits of <submodule> ever registered in this > > # project > > git submodulecheckout --find-versions <submodule> > out.tmp > > > > # This reads the previous list and outputs a list of of all the commits > > # that contain <treeish>. Function in_merge_bases(treeish, i&commit, 1) > > # can be of help here. Afterwards you have to prune all later commits > > # that contain earlier ones. I did this in find_first_merges(). I > > # suggest to refactor that code into a function so that you can use it. > > git submodulecheckout --find-closest <treeish> -- <submodule> < out.tmp > out2.tmp > > > > # And now we can search for the commit in the other submodule C > > git submodulecheckout --list-commits <other submodule> < out2.tmp > out3.tmp > > > > And if out3.tmp just contained one line we could checkout that one. I am > > still not sure in which command these options could go. Junio do you > > maybe have a suggestion? Since its all about submodules it would make > > sense to put it in 'git submodule' but thats already the script. > > > > Maybe a new 'git-submodule-tool' ? > > Before I wanted to name it submodule-checkout but I think I hade a > naming conflict issue with submodule... not sure if submodule-tool > will work... Since the submodule script might be obsoleted partly and get rewritten in C at some point I was thinking of this as a kind of intermediate internal submodule helper tool. Cheers Heiko ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository 2011-02-14 21:13 ` Heiko Voigt @ 2011-02-20 1:15 ` Julian Ibarz 0 siblings, 0 replies; 20+ messages in thread From: Julian Ibarz @ 2011-02-20 1:15 UTC (permalink / raw) To: Heiko Voigt; +Cc: Junio C Hamano, Jens Lehmann, git On Mon, Feb 14, 2011 at 4:13 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote: > Hi, > > On Sun, Feb 13, 2011 at 01:59:09PM -0500, Julian Ibarz wrote: >> On Sun, Feb 13, 2011 at 8:30 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote: >> > Ok lets not be so hard: >> > >> > git checkout v1.7.2.3.msysgit.0 >> > cd .. >> > git submodulecheckout --find-versions git > git-versions.txt >> > cd git >> > git submodulecheckout --find-closest < ../git-versions.txt >> >> 820fd48475eb72cdd4f2 >> > >> > Close but not quite the right commit. See the output of git log: >> > 820fd48 Chomp CRLF before feeding to tar when building netinstaller. >> > 83e164c Avoid quoting environment variable values. >> > daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3 >> > >> > Whats strange is that this commit did not even change the submodule. >> >> Well because it is _exactly_ the commit that point to the current >> submodule version you have checked out :) So it _is_ the good version. >> Which version were you thinking was good? > > Well I think the interface was/is still confusing me. Once you change to > one where I can specify the hash I want to search for I will give it > another try. >> > I think currently it does not make sense to implement the scripting >> > since the interface is not yet cleaned up enough. It should be possible >> > to specify a commit as parameter and the path should probably go after >> > that like the other commands do as well. >> > >> > The other issue is that we need to change the working directory. IMO, >> > everything should be possible to do from superproject. Have a look at >> > add_submodule_odb() in submodule.c it lets you load the database of a >> > submodule. This way you can run the --find-closest from the superproject. >> >> I don't think we want to do that. The usual scenario is: >> >> * you are in a submodule >> * you checkout a specific version >> * you want the meta-repo and side submodules to be updated accordingly >> >> And in this scenario at the beginning you are at the submodule >> directory, not the meta repository so... What do you think? Also even >> if in these low-level commands you need to change directory, if it is >> hided in an integration in the sh submodule script, it doesn't matter >> right? > > Well I think the interface should be useable by hand also. Lots of tools > in git were invented by plugging the tools together differently than the > original developer even had in his mind. So a nice "do only one thing > but that very good" kind of interface makes sense. > > I think a nice thing would be if you could stay in one directory and it > should not be too hard since we have add_submodule_odb(). Implementation > would be easier if we started this command from the supermodule since > searching for a supermodule from a submodule is still missing. > >> > So what I would be looking for is something like this: >> > >> > # This looks up all commits of <submodule> ever registered in this >> > # project >> > git submodulecheckout --find-versions <submodule> > out.tmp >> > >> > # This reads the previous list and outputs a list of of all the commits >> > # that contain <treeish>. Function in_merge_bases(treeish, i&commit, 1) >> > # can be of help here. Afterwards you have to prune all later commits >> > # that contain earlier ones. I did this in find_first_merges(). I >> > # suggest to refactor that code into a function so that you can use it. >> > git submodulecheckout --find-closest <treeish> -- <submodule> < out.tmp > out2.tmp >> > >> > # And now we can search for the commit in the other submodule C >> > git submodulecheckout --list-commits <other submodule> < out2.tmp > out3.tmp >> > >> > And if out3.tmp just contained one line we could checkout that one. I am >> > still not sure in which command these options could go. Junio do you >> > maybe have a suggestion? Since its all about submodules it would make >> > sense to put it in 'git submodule' but thats already the script. >> > >> > Maybe a new 'git-submodule-tool' ? >> >> Before I wanted to name it submodule-checkout but I think I hade a >> naming conflict issue with submodule... not sure if submodule-tool >> will work... > > Since the submodule script might be obsoleted partly and get rewritten > in C at some point I was thinking of this as a kind of intermediate > internal submodule helper tool. > > Cheers Heiko > Today I have added the possibility to provide a hash to find-closest feature. I have also implemented the two optimizations I was talking about and now it is pretty fast. By the way I am using the binary tree from string-list.h. An example of execution: git submodulecheckout --find-closest v1.7.3.1.msysgit.0 < ../git-versions.txt 279f4c28cad4bd97dc06129118314b0a36f193db 468fabbff85c10e5e226a2ea22699cd4186536f7 fe61e4c51c9f3577fcb85951f72d3c65afce251d The first commit is the closest referenced commit found starting from v1.7.3.1.msysgit.0 and then the last two are the commits in the parent repository that reference this commit. If we integrate this in git-submodule.sh, the script could take those hash and instead display them + first line of commit message and the tags if there is one. As for your third command --list-commits I don't think it matters. As soon as the user has decided which commit in the parent repository he wants to checkout, then we just need to git submodule update everything except the submodule that helped us find it. Basically from the example above. if we say that 468fabbff85c10e5e226a2ea22699cd4186536f7 is the commit we were looking for for msysgit then we can do git submodule update on everything except submodule git. Next on my TODO list: * Optimize find-versions using string-list * Run find-closest in the meta-repository instead * Implement a test example Let me know if I am missing something. Best regards, Julian ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-02-20 1:15 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 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
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).