{"thread":{"id":"26340","subject":"Updating a submodule with a compatible version from another submodule version using the parent meta-repository","startedAt":"2011-01-26T18:32:33Z","lastAt":"2011-02-20T01:15:08Z","messageCount":20,"participants":["Julian Ibarz","Jens Lehmann","Junio C Hamano","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159898","messageId":"AANLkTimvNaiieEw8-Y52xxDW6DQ6b16v9azCk+BDPxhe@mail.gmail.com","threadId":"26340","inReplyTo":"AANLkTinN1XVsAZXGLqkuhysrJ8-TCtGm4pOu2RfCEVVp@mail.gmail.com","subject":"Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-01-26T18:32:33Z","receivedAt":"2011-01-26T18:32:33Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"I am using git submodule in one of my professional projects and I am\nfacing an issue when I am using git bisect in one of the submodules.\n\nBasically I have a meta repository which I will call A and two\nsubmodules B and C. Sometimes I use git bisect in B but it is\ndependent on C so when I go back too much in the history of B, C needs\nto change its version to a compatible one. Doing this manually is\nreally time consuming for me and I guess a lot of people have this\nissue so I was a little bit surprise to not find easily anything on\nthe net that permits to do this automatically.\n\nIs there anything existing to do that and I just didn't find it yet?\nIf not I think I might have an implementation idea I would like to try\nout.\n\nThanks for your time,\n\nJulian Ibarz\n"},{"id":"159900","messageId":"4D407099.4010805@web.de","threadId":"26340","inReplyTo":"AANLkTimvNaiieEw8-Y52xxDW6DQ6b16v9azCk+BDPxhe@mail.gmail.com","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-01-26T19:06:01Z","receivedAt":"2011-01-26T19:06:01Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.01.2011 19:32, schrieb Julian Ibarz:\n> I am using git submodule in one of my professional projects and I am\n> facing an issue when I am using git bisect in one of the submodules.\n> \n> Basically I have a meta repository which I will call A and two\n> submodules B and C. Sometimes I use git bisect in B but it is\n> dependent on C so when I go back too much in the history of B, C needs\n> to change its version to a compatible one. Doing this manually is\n> really time consuming for me and I guess a lot of people have this\n> issue so I was a little bit surprise to not find easily anything on\n> the net that permits to do this automatically.\n\nWhat about bisecting in A (doing \"git submodule update\" after every\nstep) to bisect to a smaller range of commits in B (which are then\nnot dependent on your submodule C anymore and can be bisected inside\nB)? This of course assumes A properly records the dependencies\nbetween B and C.\n\n> Is there anything existing to do that and I just didn't find it yet?\n> If not I think I might have an implementation idea I would like to try\n> out.\n\nThe call to \"git submodule update\" after each bisect step in the\nsuperproject will be obsolete as soon as the recursive checkout\nI am currently working on is done, but that is not here yet.\n"},{"id":"159901","messageId":"AANLkTinMhvBNrBMJ8vQpJdYxP_NgJU2L7JEW0KhXGjhf@mail.gmail.com","threadId":"26340","inReplyTo":"4D407099.4010805@web.de","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-01-26T19:10:32Z","receivedAt":"2011-01-26T19:10:32Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann wrote:\n> Am 26.01.2011 19:32, schrieb Julian Ibarz:\n>> I am using git submodule in one of my professional projects and I am\n>> facing an issue when I am using git bisect in one of the submodules.\n>>\n>> Basically I have a meta repository which I will call A and two\n>> submodules B and C. Sometimes I use git bisect in B but it is\n>> dependent on C so when I go back too much in the history of B, C needs\n>> to change its version to a compatible one. Doing this manually is\n>> really time consuming for me and I guess a lot of people have this\n>> issue so I was a little bit surprise to not find easily anything on\n>> the net that permits to do this automatically.\n>\n> What about bisecting in A (doing \"git submodule update\" after every\n> step) to bisect to a smaller range of commits in B (which are then\n> not dependent on your submodule C anymore and can be bisected inside\n> B)? This of course assumes A properly records the dependencies\n> between B and C.\n\nYes but actually my real use case that made me write this mail was\nmore I have a feature done in an old branch and to try it I never to\nrevert back to this version. In this case, I have to find out the\ncorresponding good version in A and C. In this case I cannot start\nlike what you propose in A to find out the good version in B and C, I\nalready know the version I want in B.\n\n>> Is there anything existing to do that and I just didn't find it yet?\n>> If not I think I might have an implementation idea I would like to try\n>> out.\n>\n> The call to \"git submodule update\" after each bisect step in the\n> superproject will be obsolete as soon as the recursive checkout\n> I am currently working on is done, but that is not here yet.\n\nCan you be more detailed about your recursive checkout feature? Is it\nwhat I proposed?\n"},{"id":"159902","messageId":"4D407875.7080607@web.de","threadId":"26340","inReplyTo":"AANLkTinMhvBNrBMJ8vQpJdYxP_NgJU2L7JEW0KhXGjhf@mail.gmail.com","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-01-26T19:39:33Z","receivedAt":"2011-01-26T19:39:33Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.01.2011 20:10, schrieb Julian Ibarz:\n> On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann wrote:\n>> Am 26.01.2011 19:32, schrieb Julian Ibarz:\n>>> I am using git submodule in one of my professional projects and I am\n>>> facing an issue when I am using git bisect in one of the submodules.\n>>>\n>>> Basically I have a meta repository which I will call A and two\n>>> submodules B and C. Sometimes I use git bisect in B but it is\n>>> dependent on C so when I go back too much in the history of B, C needs\n>>> to change its version to a compatible one. Doing this manually is\n>>> really time consuming for me and I guess a lot of people have this\n>>> issue so I was a little bit surprise to not find easily anything on\n>>> the net that permits to do this automatically.\n>>\n>> What about bisecting in A (doing \"git submodule update\" after every\n>> step) to bisect to a smaller range of commits in B (which are then\n>> not dependent on your submodule C anymore and can be bisected inside\n>> B)? This of course assumes A properly records the dependencies\n>> between B and C.\n> \n> Yes but actually my real use case that made me write this mail was\n> more I have a feature done in an old branch and to try it I never to\n> revert back to this version. In this case, I have to find out the\n> corresponding good version in A and C. In this case I cannot start\n> like what you propose in A to find out the good version in B and C, I\n> already know the version I want in B.\n\nHmm, looks like I lost you here ... you want to bisect in B although\nyou know what commit you want there? Care to explain a bit more?\n\n>>> Is there anything existing to do that and I just didn't find it yet?\n>>> If not I think I might have an implementation idea I would like to try\n>>> out.\n>>\n>> The call to \"git submodule update\" after each bisect step in the\n>> superproject will be obsolete as soon as the recursive checkout\n>> I am currently working on is done, but that is not here yet.\n> \n> Can you be more detailed about your recursive checkout feature? Is it\n> what I proposed?\n\nI don't think so, that will just get rid of the extra call to \"git\nsubmodule update\" when bisecting in A.\n"},{"id":"159903","messageId":"AANLkTik-XdgGM20kFu8KZ5k9ynfNAo8fvL9t7kL_JhQg@mail.gmail.com","threadId":"26340","inReplyTo":"4D407875.7080607@web.de","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-01-26T19:48:14Z","receivedAt":"2011-01-26T19:48:14Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"> Am 26.01.2011 20:10, schrieb Julian Ibarz:\n>> On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann wrote:\n>>> Am 26.01.2011 19:32, schrieb Julian Ibarz:\n>>>> I am using git submodule in one of my professional projects and I am\n>>>> facing an issue when I am using git bisect in one of the submodules.\n>>>>\n>>>> Basically I have a meta repository which I will call A and two\n>>>> submodules B and C. Sometimes I use git bisect in B but it is\n>>>> dependent on C so when I go back too much in the history of B, C needs\n>>>> to change its version to a compatible one. Doing this manually is\n>>>> really time consuming for me and I guess a lot of people have this\n>>>> issue so I was a little bit surprise to not find easily anything on\n>>>> the net that permits to do this automatically.\n>>>\n>>> What about bisecting in A (doing \"git submodule update\" after every\n>>> step) to bisect to a smaller range of commits in B (which are then\n>>> not dependent on your submodule C anymore and can be bisected inside\n>>> B)? This of course assumes A properly records the dependencies\n>>> between B and C.\n>>\n>> Yes but actually my real use case that made me write this mail was\n>> more I have a feature done in an old branch and to try it I never to\n>> revert back to this version. In this case, I have to find out the\n>> corresponding good version in A and C. In this case I cannot start\n>> like what you propose in A to find out the good version in B and C, I\n>> already know the version I want in B.\n>\n> Hmm, looks like I lost you here ... you want to bisect in B although\n> you know what commit you want there? Care to explain a bit more?\n\nIn B I have a feature to integrate in master branch. This feature is\nin branch old_feature. But this branch is really old. To try this\nfeature I need to rebuild it at this version. To make the build\nsuccess I need also to revert back the submodule C because B is\ndependent on it. But finding the good version of C that match\nold_feature version is a pain... Is it clear?\n\n>>>> Is there anything existing to do that and I just didn't find it yet?\n>>>> If not I think I might have an implementation idea I would like to try\n>>>> out.\n>>>\n>>> The call to \"git submodule update\" after each bisect step in the\n>>> superproject will be obsolete as soon as the recursive checkout\n>>> I am currently working on is done, but that is not here yet.\n>>\n>> Can you be more detailed about your recursive checkout feature? Is it\n>> what I proposed?\n>\n> I don't think so, that will just get rid of the extra call to \"git\n> submodule update\" when bisecting in A.\n\nBasically my feature would work like this:\n\nin B:\ngit submodule checkout some_version\n\nThis will checkout B but also change A and C so that it is compatible\nwith some_version of B. Basically it will find the commit in A that\nhas the closest parent commit of some_version in B. When this is done\nit just does git submodule udate on other submodules.\n\nI see in gitk that there is a feature that has a common implementation\nfor what I want to do:\n\nFor every commits you can see Follows and Precedes which lists the\nclosest label before this release and after. What I need is the same\nthing: instead of finding a closest labeled commit, I need to find a\nclosest commit referenced by A that precedes current HEAD of B. When\nthis is done I know which commit A has to be and then just have to\ncall git submodule update in A (update every other submodules except\nfor B).\n\nJulian\n"},{"id":"159905","messageId":"4D40849C.2050903@web.de","threadId":"26340","inReplyTo":"AANLkTik-XdgGM20kFu8KZ5k9ynfNAo8fvL9t7kL_JhQg@mail.gmail.com","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-01-26T20:31:24Z","receivedAt":"2011-01-26T20:31:24Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.01.2011 20:48, schrieb Julian Ibarz:\n> Basically my feature would work like this:\n> \n> in B:\n> git submodule checkout some_version\n> \n> This will checkout B but also change A and C so that it is compatible\n> with some_version of B. Basically it will find the commit in A that\n> has the closest parent commit of some_version in B. When this is done\n> it just does git submodule udate on other submodules.\n\nThanks, now I understand what you are trying to achieve.\n\n> I see in gitk that there is a feature that has a common implementation\n> for what I want to do:\n> \n> For every commits you can see Follows and Precedes which lists the\n> closest label before this release and after. What I need is the same\n> thing: instead of finding a closest labeled commit, I need to find a\n> closest commit referenced by A that precedes current HEAD of B. When\n> this is done I know which commit A has to be and then just have to\n> call git submodule update in A (update every other submodules except\n> for B).\n\nI am not aware of something like that in current Git, But I see that\nsuch functionality would be helpful. Care to share your implementation\nidea?\n"},{"id":"159908","messageId":"7v7hdrl7nw.fsf@alter.siamese.dyndns.org","threadId":"26340","inReplyTo":"AANLkTik-XdgGM20kFu8KZ5k9ynfNAo8fvL9t7kL_JhQg@mail.gmail.com","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-26T20:41:23Z","receivedAt":"2011-01-26T20:41:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Ibarz writes:\n\n>> Hmm, looks like I lost you here ... you want to bisect in B although\n>> you know what commit you want there? Care to explain a bit more?\n>\n> In B I have a feature to integrate in master branch. This feature is\n> in branch old_feature. But this branch is really old. To try this\n> feature I need to rebuild it at this version. To make the build\n> success I need also to revert back the submodule C because B is\n> dependent on it. But finding the good version of C that match\n> old_feature version is a pain... Is it clear?\n\nThat sounds like bisecting in C with a frozen checkout of B to see which\nversion in C works well with that target commit in B you know you want to\nuse. Why do you need to bisect in B???\n"},{"id":"159910","messageId":"AANLkTimtHL3gLXgfvmWDg82tFCjW24srUN5vW92bTSx5@mail.gmail.com","threadId":"26340","inReplyTo":"4D40849C.2050903@web.de","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-01-26T20:43:38Z","receivedAt":"2011-01-26T20:43:38Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"> Am 26.01.2011 20:48, schrieb Julian Ibarz:\n>> Basically my feature would work like this:\n>>\n>> in B:\n>> git submodule checkout some_version\n>>\n>> This will checkout B but also change A and C so that it is compatible\n>> with some_version of B. Basically it will find the commit in A that\n>> has the closest parent commit of some_version in B. When this is done\n>> it just does git submodule udate on other submodules.\n>\n> Thanks, now I understand what you are trying to achieve.\n>\n>> I see in gitk that there is a feature that has a common implementation\n>> for what I want to do:\n>>\n>> For every commits you can see Follows and Precedes which lists the\n>> closest label before this release and after. What I need is the same\n>> thing: instead of finding a closest labeled commit, I need to find a\n>> closest commit referenced by A that precedes current HEAD of B. When\n>> this is done I know which commit A has to be and then just have to\n>> call git submodule update in A (update every other submodules except\n>> for B).\n>\n> I am not aware of something like that in current Git, But I see that\n> such functionality would be helpful. Care to share your implementation\n> idea?\n\nWell actually the paragraph just above is what is my implementation\nidea. I recognize it is really high level but it is still a start ;).\nBasically the \"complex\" part is to find the precedent commit in B that\nis referenced by A. Since gitk has this already but for labels, we\njust need to reuse/copy their function that does this but instead as\ninput having a list of commit labels and find the closest precedent it\nis instead the list of commits referenced by A. By the way, anyone\nreading this knows where it is in the code of gitk? Or if there is\nsomething like that already in the git code? I never looked into both\ncode projects.\n"},{"id":"159911","messageId":"AANLkTik8VrhbBSLwRq9gd39hofnmifk15zSqXVTsSzAp@mail.gmail.com","threadId":"26340","inReplyTo":"7v7hdrl7nw.fsf@alter.siamese.dyndns.org","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-01-26T20:45:38Z","receivedAt":"2011-01-26T20:45:38Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"On Wed, Jan 26, 2011 at 3:41 PM, Junio C Hamano wrote:\n> Julian Ibarz writes:\n>\n>>> Hmm, looks like I lost you here ... you want to bisect in B although\n>>> you know what commit you want there? Care to explain a bit more?\n>>\n>> In B I have a feature to integrate in master branch. This feature is\n>> in branch old_feature. But this branch is really old. To try this\n>> feature I need to rebuild it at this version. To make the build\n>> success I need also to revert back the submodule C because B is\n>> dependent on it. But finding the good version of C that match\n>> old_feature version is a pain... Is it clear?\n>\n> That sounds like bisecting in C with a frozen checkout of B to see which\n> version in C works well with that target commit in B you know you want to\n> use.  Why do you need to bisect in B???\n>\n\nForget about bisect. This is a different use case where I need the\nfeature I am talking about: checkout an old version in B and\nautomatically having A and C switch to a compatible version (the cause\ncan be because of a bisect or just because I want to try an old\nfeature not yet integrated into master or whatever the reason I want\nto be on this old version).\n"},{"id":"159926","messageId":"7v1v3zjp6w.fsf@alter.siamese.dyndns.org","threadId":"26340","inReplyTo":"AANLkTik8VrhbBSLwRq9gd39hofnmifk15zSqXVTsSzAp@mail.gmail.com","subject":"Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-26T22:05:43Z","receivedAt":"2011-01-26T22:05:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Ibarz writes:\n\n> On Wed, Jan 26, 2011 at 3:41 PM, Junio C Hamano wrote:\n>> Julian Ibarz writes:\n>>\n>>>> Hmm, looks like I lost you here ... you want to bisect in B although\n>>>> you know what commit you want there? Care to explain a bit more?\n>>>\n>>> In B I have a feature to integrate in master branch. This feature is\n>>> in branch old_feature. But this branch is really old. To try this\n>>> feature I need to rebuild it at this version. To make the build\n>>> success I need also to revert back the submodule C because B is\n>>> dependent on it. But finding the good version of C that match\n>>> old_feature version is a pain... Is it clear?\n>>\n>> That sounds like bisecting in C with a frozen checkout of B to see which\n>> version in C works well with that target commit in B you know you want to\n>> use.  Why do you need to bisect in B???\n>\n> Forget about bisect. This is a different use case where I need the\n> feature I am talking about: checkout an old version in B and\n> automatically having A and C switch to a compatible version (the cause\n> can be because of a bisect or just because I want to try an old\n> feature not yet integrated into master or whatever the reason I want\n> to be on this old version).\n\nIf that version of submodule B is explicitly bound to a commit in the\nsuperproject A, you know which version of A and C were recorded, and the\nproblem is solved.\n\nBut otherwise, you are wishing for a miracle, I am afraid, without giving\nyour tool (git or your own tool you write on top of it) some hint to say\nhow \"similar\" commits in B are, as there is no guarantee that anybody even\ntried a commit that is not directly referenced from the superproject\ntogether with other parts of the system.\n\nIf you are confident that you didn't introduce different kind of\ndependency to other submodules while developing your \"old_feature\" branch\nin submodule B, one strategy may be to find an ancestor, preferrably the\nfork point, of your \"old_feature\" branch that is bound to the superproject\nA. Then at that point at least you know whoever made that commit in A\ntested the combination of what was recorded in that commit, together with\nthe version of B and C, and you can go forward from there, replaying the\nchanges you made to the \"old_feature\" branch in submodule B.\n"},{"id":"160023","messageId":"20110129110807.GA21864@book.hvoigt.net","threadId":"26340","inReplyTo":"7v1v3zjp6w.fsf@alter.siamese.dyndns.org","subject":"Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-01-29T11:08:08Z","receivedAt":"2011-01-29T11:08:08Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote:\n> If that version of submodule B is explicitly bound to a commit in the\n> superproject A, you know which version of A and C were recorded, and the\n> problem is solved.\n> \n[...]\n> \n> If you are confident that you didn't introduce different kind of\n> dependency to other submodules while developing your \"old_feature\" branch\n> in submodule B, one strategy may be to find an ancestor, preferrably the\n> fork point, of your \"old_feature\" branch that is bound to the superproject\n> A. Then at that point at least you know whoever made that commit in A\n> tested the combination of what was recorded in that commit, together with\n> the version of B and C, and you can go forward from there, replaying the\n> changes you made to the \"old_feature\" branch in submodule B.\n\nLets extend your explanation a little further and maybe demonstrate the problem\nJulian is having a little more. I think what Julian searches for is a tool in\ngit that does the lookup for you which is AFAIK not that easy currently. It\nseems to be a quite useful feature. Here what I understand Julian wants:\n\n1. Find the most recent superproject commit X'' in A that records a submodule\n commit X' in B which contains the commit X in B you are searching for.\n\n For this we would need use something similar to git describe --contains\n but instead of using the list of existing tags in B it should use the list\n of commits in B which are recorded in A.\n\n Here a drawing to explain (linear history for simplicity):\n\n superproject A:\n\n O---O---X''---O\n \\\n submodule B: \\\n \\\n O---X---O---X'---O---O\n\n2. Look up the commit of C which is recorded in X'' of A and check it\n out.\n\nStep 2 is easy but for Step 1 the lookup of X' is missing for the commandline.\nIs there already anything that implements git describe --contains for a defined\nlist of commits instead of refs?\n\nCheers Heiko\n"},{"id":"160047","messageId":"AANLkTimBCeSnR270eWMcrgCVj6rmiRkJizOxQPAPOAnn@mail.gmail.com","threadId":"26340","inReplyTo":"20110129110807.GA21864@book.hvoigt.net","subject":"Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-01-30T09:44:59Z","receivedAt":"2011-01-30T09:44:59Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"Today I have started to implement a proof of concept in C (I know a\nscript would be better but I am really not good in sh so...). I\nstruggle with the manipulation of the git API. I have pushed my work\nhere:\n\nhttp://gitorious.org/julian_ibarz_git/julian_ibarz_git\n\nin branch submodule_checkout\n\nMy work is in:\n\nbuiltin/submodulecheckout.c\n\nAnd my questions are prepended by the keyword QUESTION (two questions\nfor now only).\n\nAny help is welcome.\n\nThanks,\n\nJulian Ibarz\n\nOn Sat, Jan 29, 2011 at 6:08 AM, Heiko Voigt wrote:\n> Hi,\n>\n> On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote:\n>> If that version of submodule B is explicitly bound to a commit in the\n>> superproject A, you know which version of A and C were recorded, and the\n>> problem is solved.\n>>\n> [...]\n>>\n>> If you are confident that you didn't introduce different kind of\n>> dependency to other submodules while developing your \"old_feature\" branch\n>> in submodule B, one strategy may be to find an ancestor, preferrably the\n>> fork point, of your \"old_feature\" branch that is bound to the superproject\n>> A.  Then at that point at least you know whoever made that commit in A\n>> tested the combination of what was recorded in that commit, together with\n>> the version of B and C, and you can go forward from there, replaying the\n>> changes you made to the \"old_feature\" branch in submodule B.\n>\n> Lets extend your explanation a little further and maybe demonstrate the problem\n> Julian is having a little more. I think what Julian searches for is a tool in\n> git that does the lookup for you which is AFAIK not that easy currently. It\n> seems to be a quite useful feature. Here what I understand Julian wants:\n>\n> 1. Find the most recent superproject commit X'' in A that records a submodule\n>   commit X' in B which contains the commit X in B you are searching for.\n>\n>   For this we would need use something similar to git describe --contains\n>   but instead of using the list of existing tags in B it should use the list\n>   of commits in B which are recorded in A.\n>\n>   Here a drawing to explain (linear history for simplicity):\n>\n>   superproject A:\n>\n>      O---O---X''---O\n>               \\\n>   submodule B: \\\n>                 \\\n>      O---X---O---X'---O---O\n>\n> 2. Look up the commit of C which is recorded in X'' of A and check it\n>   out.\n>\n> Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline.\n> Is there already anything that implements git describe --contains for a defined\n> list of commits instead of refs?\n>\n> Cheers Heiko\n>\n"},{"id":"160306","messageId":"AANLkTim2G0kF+omPZ1_fk0P6oGDaKDWd79XNR5GXUkWG@mail.gmail.com","threadId":"26340","inReplyTo":"AANLkTimBCeSnR270eWMcrgCVj6rmiRkJizOxQPAPOAnn@mail.gmail.com","subject":"Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-02-03T04:31:40Z","receivedAt":"2011-02-03T04:31:40Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"Hi,\n\nAfter a couple of hours, I have finally succeeded to go through the\nentire history of a repository and I can detect the submodules in a\ntree of a commit. For those interested here is the source code:\n\nhttp://gitorious.org/julian_ibarz_git/julian_ibarz_git/blobs/submodule_checkout/builtin/submodulecheckout.c\n\nNext time I will build the list of commits of a submodule in the\nentire history. Then I will need to find the distance of each commit\nin the list compared to the current commit of a submodule and keep\nthe closest one (which has to be a parent so an algebric distance\nwould be good to have).\n\nSo now my two questions that could save me some time are:\n- is there a function that gives the distance between two commits? I'm\nsure there is something like this coded somewhere but I didn't find it\nyet\n- is the struct decorate a hash map and if yes could someone explain\nme how to use it or point me to a location where it is used?\n\nExcept from that I think I have all the information I need.\n\nBest regards,\nJulian Ibarz\n\nOn Sun, Jan 30, 2011 at 4:44 AM, Julian Ibarz wrote:\n> Today I have started to implement a proof of concept in C (I know a\n> script would be better but I am really not good in sh so...). I\n> struggle with the manipulation of the git API. I have pushed my work\n> here:\n>\n> http://gitorious.org/julian_ibarz_git/julian_ibarz_git\n>\n> in branch submodule_checkout\n>\n> My work is in:\n>\n> builtin/submodulecheckout.c\n>\n> And my questions are prepended by the keyword QUESTION (two questions\n> for now only).\n>\n> Any help is welcome.\n>\n> Thanks,\n>\n> Julian Ibarz\n>\n> On Sat, Jan 29, 2011 at 6:08 AM, Heiko Voigt wrote:\n>> Hi,\n>>\n>> On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote:\n>>> If that version of submodule B is explicitly bound to a commit in the\n>>> superproject A, you know which version of A and C were recorded, and the\n>>> problem is solved.\n>>>\n>> [...]\n>>>\n>>> If you are confident that you didn't introduce different kind of\n>>> dependency to other submodules while developing your \"old_feature\" branch\n>>> in submodule B, one strategy may be to find an ancestor, preferrably the\n>>> fork point, of your \"old_feature\" branch that is bound to the superproject\n>>> A.  Then at that point at least you know whoever made that commit in A\n>>> tested the combination of what was recorded in that commit, together with\n>>> the version of B and C, and you can go forward from there, replaying the\n>>> changes you made to the \"old_feature\" branch in submodule B.\n>>\n>> Lets extend your explanation a little further and maybe demonstrate the problem\n>> Julian is having a little more. I think what Julian searches for is a tool in\n>> git that does the lookup for you which is AFAIK not that easy currently. It\n>> seems to be a quite useful feature. Here what I understand Julian wants:\n>>\n>> 1. Find the most recent superproject commit X'' in A that records a submodule\n>>   commit X' in B which contains the commit X in B you are searching for.\n>>\n>>   For this we would need use something similar to git describe --contains\n>>   but instead of using the list of existing tags in B it should use the list\n>>   of commits in B which are recorded in A.\n>>\n>>   Here a drawing to explain (linear history for simplicity):\n>>\n>>   superproject A:\n>>\n>>      O---O---X''---O\n>>               \\\n>>   submodule B: \\\n>>                 \\\n>>      O---X---O---X'---O---O\n>>\n>> 2. Look up the commit of C which is recorded in X'' of A and check it\n>>   out.\n>>\n>> Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline.\n>> Is there already anything that implements git describe --contains for a defined\n>> list of commits instead of refs?\n>>\n>> Cheers Heiko\n>>\n>\n"},{"id":"160540","messageId":"20110206185140.GA61833@book.hvoigt.net","threadId":"26340","inReplyTo":"AANLkTim2G0kF+omPZ1_fk0P6oGDaKDWd79XNR5GXUkWG@mail.gmail.com","subject":"Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-06T18:51:41Z","receivedAt":"2011-02-06T18:51:41Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi Julian,\n\ninteresting work so far.\n\nOne thing regarding the mailing list: Please do not top post and try to cut non\nrelevant text (the one you are not replying to) from your replies.\n\nOn Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote:\n> After a couple of hours, I have finally succeeded to go through the\n> entire history of a repository and I can detect the submodules in a\n> tree of a commit. For those interested here is the source code:\n> \n> http://gitorious.org/julian_ibarz_git/julian_ibarz_git/blobs/submodule_checkout/builtin/submodulecheckout.c\n> \n> Next time I will build the list of commits of a submodule in the\n> entire history.\n\nSounds great. That will be one tool you need. Here is a small script\nsnippet which already does that as an example for the msysgit repository\n(git://repo.or.cz/msysgit.git):\n\nexport sub=git\ngit log --pretty=\"%h\" -- $sub | \\\n while read i; do git ls-tree $i -- $sub; done | \\\n cut -f3 -d\" \" | cut -f1\n\nIt outputs all the hashes that have been registered for the git\nsubmodule. Maybe thats a good starting point to find example code in C.\nYou can use it for other submodules also just change the name in the variable\nsub.\n\n> Then I will need to find the distance of each commit\n> in the list compared to the current commit of a submodule and keep\n> the closest one (which has to be a parent so an algebric distance\n> would be good to have).\n\nHave a look at the codepath that is used for\n\n git branch --contains \n\nIt essentially does the thing you want (find all refs that contain a\ncommit). An approach could be to extend this mechanism not to iterate\nthrough all refs but e.g. take a list of sha1's for iteration.\n\n> So now my two questions that could save me some time are:\n> - is there a function that gives the distance between two commits? I'm\n> sure there is something like this coded somewhere but I didn't find it\n> yet\n> - is the struct decorate a hash map and if yes could someone explain\n> me how to use it or point me to a location where it is used?\n\nPlease see the tips above.\n\n> Except from that I think I have all the information I need.\n\nThere are a few points I would like to mention:\n\n * Citing my drawing:\n> >>   superproject A:\n> >>\n> >>      O---O---X''---O\n> >>               \\\n> >>   submodule B: \\\n> >>                 \\\n> >>      O---X---O---X'---O---O\n\n There can be multiple X' which contain X. These are all valid\n candidates. The same applies to X'' where there can be multiple\n candidates that record a specific X'. IMO, all of them need to be\n considered. If in the end they all reduce to one commit in submodule C\n you can check that out. If not printing a list of all candidates is\n probably the best option.\n\n * If we want your code to go upstream it probably needs to be\n integrated as a subcommand into the current submodule script. I can\n offer to help you on the bash scripting side. I think once the tools\n to find the appropriate commits are ready that will not be a big\n issue.\n\n * I think for protoyping the tools you can later use in the submodule\n script its fine to implement your own command. Keep in mind that you\n later on you should probably integrate your code into the appropriate\n existing commands. Here some suggestions.\n\n To support proper bash scripting two parts come into my mind:\n\n 1. A tool to output all of the submodules commits which are\n candidates for X'' like the script snippet above.\n\n 2. A tool that takes the list from 1. and then reduces that list to\n a list of commits that actually register the possible commits X'.\n If that is one commit X'' we can directly checkout. If not we\n print the list in a nice format and let the user choose.\n\nLooking forward to your work.\n\nCheers Heiko\n"},{"id":"160779","messageId":"20110209193610.GA67890@book.hvoigt.net","threadId":"26340","inReplyTo":"AANLkTim2G0kF+omPZ1_fk0P6oGDaKDWd79XNR5GXUkWG@mail.gmail.com","subject":"Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-09T19:36:11Z","receivedAt":"2011-02-09T19:36:11Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi Julian,\n\nOn Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote:\n> So now my two questions that could save me some time are:\n> - is there a function that gives the distance between two commits? I'm\n> sure there is something like this coded somewhere but I didn't find it\n> yet\n\nOne thing which now came to my mind is that you might be interested in\nis to use merge bases to find the earliest commit that contains a\ncertain revision.\n\nHave a look at how I implemented the submodule merge strategy that might\nhelp you. You can find it in commit 68d03e4a. I basically do a search\nfor the earliest commit that contains the commits from both sides. You\ncould use a similar strategy but limit the possible candidates to a\nrestricted list of commits which are contained in the supermodule.\n\nCheers Heiko\n"},{"id":"160957","messageId":"AANLkTimist_GXgRGdUW1PpxpRO=poYgD4HkDC5CsyLra@mail.gmail.com","threadId":"26340","inReplyTo":"20110209193610.GA67890@book.hvoigt.net","subject":"Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-02-12T20:32:43Z","receivedAt":"2011-02-12T20:32:43Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"Hi Heiko,\n\nThanks for all your feedbacks. Before your first mail I had already\nimplemented command 1 you are talking about and almost finished\ncommand 2. Today I could spend some time again on this side project\nand I have finished command 2. Here is what you do:\n\ngit submodulecheckout --find-versions > \ncd \ngit submodulecheckout --find-closest < \n\nThis will output the version you need to checkout in the meta\nrepository. I don't handle the case where there is multiple solutions\nbut it is a good start I think. I think with this you can already\nstart the integration in the submodule bash script to make it\nrecursive and be more user-friendly? Are you still interested Heiko?\n\nI have pushed this to my repository so you can check it out if you want.\n\nBoth commands have a suboptimal implementation but it can be improved\nwithout changing the current API so I think it is a minor issue. I\nwill probably try this at work today on msysgit. Currently I am doing\nthis at home on my linux using some open source meta-repository, if\nyou have a big one to try this feature let me know (I am currently\nusing git://git.assembla.com/luadocsuperforest.git and it is not that\nbig).\n\nBest regards,\n\nJulian Ibarz\n\nOn Wed, Feb 9, 2011 at 2:36 PM, Heiko Voigt wrote:\n> Hi Julian,\n>\n> On Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote:\n>> So now my two questions that could save me some time are:\n>> - is there a function that gives the distance between two commits? I'm\n>> sure there is something like this coded somewhere but I didn't find it\n>> yet\n>\n> One thing which now came to my mind is that you might be interested in\n> is to use merge bases to find the earliest commit that contains a\n> certain revision.\n>\n> Have a look at how I implemented the submodule merge strategy that might\n> help you. You can find it in commit 68d03e4a. I basically do a search\n> for the earliest commit that contains the commits from both sides. You\n> could use a similar strategy but limit the possible candidates to a\n> restricted list of commits which are contained in the supermodule.\n>\n> Cheers Heiko\n>\n"},{"id":"161001","messageId":"20110213133019.GB31986@book.hvoigt.net","threadId":"26340","inReplyTo":"AANLkTimist_GXgRGdUW1PpxpRO=poYgD4HkDC5CsyLra@mail.gmail.com","subject":"Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-13T13:30:19Z","receivedAt":"2011-02-13T13:30:19Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi Julian,\n\nOn Sat, Feb 12, 2011 at 03:32:43PM -0500, Julian Ibarz wrote:\n> Thanks for all your feedbacks. Before your first mail I had already\n> implemented command 1 you are talking about and almost finished\n> command 2. Today I could spend some time again on this side project\n> and I have finished command 2. Here is what you do:\n> \n> git submodulecheckout --find-versions > \n> cd \n> git submodulecheckout --find-closest < \n\nI do not quite understand how this is used. I just tried it on the\nmsysgit repository. Which is a good candidate for testing since you can\neasily verify the results because for each git version there is a\ncorresponding tag in the superproject.\n\nYou can find it on repo: http://repo.or.cz/w/msysgit.git\n\nAs far as I understand the sha1 you are searching for is determined by\nthe currently checked out revision. So here we go:\n\ncd msysgit/git\ngit checkout v1.7.2.3.msysgit.0~3\ncd ..\ngit submodulecheckout --find-versions git > git-versions.txt\ncd git\ngit submodulecheckout --find-closest < ../git-versions.txt\n> submodulecheckout: no commit found\n\nOk lets not be so hard:\n\ngit checkout v1.7.2.3.msysgit.0\ncd ..\ngit submodulecheckout --find-versions git > git-versions.txt\ncd git\ngit submodulecheckout --find-closest < ../git-versions.txt\n> 820fd48475eb72cdd4f2\n\nClose but not quite the right commit. See the output of git log:\n820fd48 Chomp CRLF before feeding to tar when building netinstaller.\n83e164c Avoid quoting environment variable values.\ndaafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3\n\nWhats strange is that this commit did not even change the submodule.\n\nI think currently it does not make sense to implement the scripting\nsince the interface is not yet cleaned up enough. It should be possible\nto specify a commit as parameter and the path should probably go after\nthat like the other commands do as well.\n\nThe other issue is that we need to change the working directory. IMO,\neverything should be possible to do from superproject. Have a look at\nadd_submodule_odb() in submodule.c it lets you load the database of a\nsubmodule. This way you can run the --find-closest from the superproject.\n\nSo what I would be looking for is something like this:\n\n# This looks up all commits of ever registered in this\n# project\ngit submodulecheckout --find-versions > out.tmp\n\n# This reads the previous list and outputs a list of of all the commits\n# that contain . Function in_merge_bases(treeish, i&commit, 1)\n# can be of help here. Afterwards you have to prune all later commits\n# that contain earlier ones. I did this in find_first_merges(). I\n# suggest to refactor that code into a function so that you can use it.\ngit submodulecheckout --find-closest -- < out.tmp > out2.tmp\n\n# And now we can search for the commit in the other submodule C\ngit submodulecheckout --list-commits < out2.tmp > out3.tmp\n\nAnd if out3.tmp just contained one line we could checkout that one. I am\nstill not sure in which command these options could go. Junio do you\nmaybe have a suggestion? Since its all about submodules it would make\nsense to put it in 'git submodule' but thats already the script.\n\nMaybe a new 'git-submodule-tool' ?\n\nI suggest that you start implementing some basic tests if you found the\nright commits using the testsuite. Basically you build up a sample\nrepository where you know which commits of the submodules are tied\ntogether with a sequence of commands. Then you check whether your\ncommands find the correct one. Maybe have a look at the submodule\ntests Jens is implementing on his branch:\n\nhttps://github.com/jlehmann/git-submod-enhancements\n\nHope that helps.\n\nCheers Heiko\n"},{"id":"161010","messageId":"AANLkTikHS95BVV4FUjR6TjZxHOGXsje2iDxEwbt9zckh@mail.gmail.com","threadId":"26340","inReplyTo":"20110213133019.GB31986@book.hvoigt.net","subject":"Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-02-13T18:59:09Z","receivedAt":"2011-02-13T18:59:09Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"On Sun, Feb 13, 2011 at 8:30 AM, Heiko Voigt wrote:\n> Hi Julian,\n>\n> On Sat, Feb 12, 2011 at 03:32:43PM -0500, Julian Ibarz wrote:\n>> Thanks for all your feedbacks. Before your first mail I had already\n>> implemented command 1 you are talking about and almost finished\n>> command 2. Today I could spend some time again on this side project\n>> and I have finished command 2. Here is what you do:\n>>\n>> git submodulecheckout --find-versions > \n>> cd \n>> git submodulecheckout --find-closest < \n>\n> I do not quite understand how this is used. I just tried it on the\n> msysgit repository. Which is a good candidate for testing since you can\n> easily verify the results because for each git version there is a\n> corresponding tag in the superproject.\n>\n> You can find it on repo: http://repo.or.cz/w/msysgit.git\n>\n> As far as I understand the sha1 you are searching for is determined by\n> the currently checked out revision. So here we go:\n>\n> cd msysgit/git\n> git checkout v1.7.2.3.msysgit.0~3\n> cd ..\n> git submodulecheckout --find-versions git > git-versions.txt\n> cd git\n> git submodulecheckout --find-closest < ../git-versions.txt\n>> submodulecheckout: no commit found\n\nThere was multiple bugs in the version you tried and I just pushed the\nfix. It is working on my repository at work but on msysgit, just\nforget it, it is too slow. I still need to optimize it, it doesn't\nscale at all lol. But it shouldn't be a problem. The two optimizations\nI want to do:\n* use a real hash map to know if I already visited a commit\n* go through the history only once and finding the closest commit in a\nlist instead of going through the entire history for each commit of\nthe least\n\nI also need to send the list of possible commits in the\nmeta-repository instead of the first one. For msysgit sometime some\nsolutions have more than 20 possible solutions!\n\n> Ok lets not be so hard:\n>\n> git checkout v1.7.2.3.msysgit.0\n> cd ..\n> git submodulecheckout --find-versions git > git-versions.txt\n> cd git\n> git submodulecheckout --find-closest < ../git-versions.txt\n>> 820fd48475eb72cdd4f2\n>\n> Close but not quite the right commit. See the output of git log:\n> 820fd48 Chomp CRLF before feeding to tar when building netinstaller.\n> 83e164c Avoid quoting environment variable values.\n> daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3\n>\n> Whats strange is that this commit did not even change the submodule.\n\nWell because it is _exactly_ the commit that point to the current\nsubmodule version you have checked out :) So it _is_ the good version.\nWhich version were you thinking was good?\n\n> I think currently it does not make sense to implement the scripting\n> since the interface is not yet cleaned up enough. It should be possible\n> to specify a commit as parameter and the path should probably go after\n> that like the other commands do as well.\n>\n> The other issue is that we need to change the working directory. IMO,\n> everything should be possible to do from superproject. Have a look at\n> add_submodule_odb() in submodule.c it lets you load the database of a\n> submodule. This way you can run the --find-closest from the superproject.\n\nI don't think we want to do that. The usual scenario is:\n\n* you are in a submodule\n* you checkout a specific version\n* you want the meta-repo and side submodules to be updated accordingly\n\nAnd in this scenario at the beginning you are at the submodule\ndirectory, not the meta repository so... What do you think? Also even\nif in these low-level commands you need to change directory, if it is\nhided in an integration in the sh submodule script, it doesn't matter\nright?\n\n> So what I would be looking for is something like this:\n>\n> # This looks up all commits of ever registered in this\n> # project\n> git submodulecheckout --find-versions > out.tmp\n>\n> # This reads the previous list and outputs a list of of all the commits\n> # that contain . Function in_merge_bases(treeish, i&commit, 1)\n> # can be of help here. Afterwards you have to prune all later commits\n> # that contain earlier ones. I did this in find_first_merges(). I\n> # suggest to refactor that code into a function so that you can use it.\n> git submodulecheckout --find-closest -- < out.tmp > out2.tmp\n>\n> # And now we can search for the commit in the other submodule C\n> git submodulecheckout --list-commits < out2.tmp > out3.tmp\n>\n> And if out3.tmp just contained one line we could checkout that one. I am\n> still not sure in which command these options could go. Junio do you\n> maybe have a suggestion? Since its all about submodules it would make\n> sense to put it in 'git submodule' but thats already the script.\n>\n> Maybe a new 'git-submodule-tool' ?\n\nBefore I wanted to name it submodule-checkout but I think I hade a\nnaming conflict issue with submodule... not sure if submodule-tool\nwill work...\n\n> I suggest that you start implementing some basic tests if you found the\n> right commits using the testsuite. Basically you build up a sample\n> repository where you know which commits of the submodules are tied\n> together with a sequence of commands. Then you check whether your\n> commands find the correct one. Maybe have a look at the submodule\n> tests Jens is implementing on his branch:\n>\n> https://github.com/jlehmann/git-submod-enhancements\n\nI will take a look into this.\n\nThanks,\nJulian\n\n> Hope that helps.\n>\n> Cheers Heiko\n>\n"},{"id":"161104","messageId":"20110214211317.GA50815@book.hvoigt.net","threadId":"26340","inReplyTo":"AANLkTikHS95BVV4FUjR6TjZxHOGXsje2iDxEwbt9zckh@mail.gmail.com","subject":"Re: Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-14T21:13:18Z","receivedAt":"2011-02-14T21:13:18Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Sun, Feb 13, 2011 at 01:59:09PM -0500, Julian Ibarz wrote:\n> On Sun, Feb 13, 2011 at 8:30 AM, Heiko Voigt wrote:\n> > Ok lets not be so hard:\n> >\n> > git checkout v1.7.2.3.msysgit.0\n> > cd ..\n> > git submodulecheckout --find-versions git > git-versions.txt\n> > cd git\n> > git submodulecheckout --find-closest < ../git-versions.txt\n> >> 820fd48475eb72cdd4f2\n> >\n> > Close but not quite the right commit. See the output of git log:\n> > 820fd48 Chomp CRLF before feeding to tar when building netinstaller.\n> > 83e164c Avoid quoting environment variable values.\n> > daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3\n> >\n> > Whats strange is that this commit did not even change the submodule.\n> \n> Well because it is _exactly_ the commit that point to the current\n> submodule version you have checked out :) So it _is_ the good version.\n> Which version were you thinking was good?\n\nWell I think the interface was/is still confusing me. Once you change to\none where I can specify the hash I want to search for I will give it\nanother try.\n\n> > I think currently it does not make sense to implement the scripting\n> > since the interface is not yet cleaned up enough. It should be possible\n> > to specify a commit as parameter and the path should probably go after\n> > that like the other commands do as well.\n> >\n> > The other issue is that we need to change the working directory. IMO,\n> > everything should be possible to do from superproject. Have a look at\n> > add_submodule_odb() in submodule.c it lets you load the database of a\n> > submodule. This way you can run the --find-closest from the superproject.\n> \n> I don't think we want to do that. The usual scenario is:\n> \n> * you are in a submodule\n> * you checkout a specific version\n> * you want the meta-repo and side submodules to be updated accordingly\n> \n> And in this scenario at the beginning you are at the submodule\n> directory, not the meta repository so... What do you think? Also even\n> if in these low-level commands you need to change directory, if it is\n> hided in an integration in the sh submodule script, it doesn't matter\n> right?\n\nWell I think the interface should be useable by hand also. Lots of tools\nin git were invented by plugging the tools together differently than the\noriginal developer even had in his mind. So a nice \"do only one thing\nbut that very good\" kind of interface makes sense.\n\nI think a nice thing would be if you could stay in one directory and it\nshould not be too hard since we have add_submodule_odb(). Implementation\nwould be easier if we started this command from the supermodule since\nsearching for a supermodule from a submodule is still missing.\n\n> > So what I would be looking for is something like this:\n> >\n> > # This looks up all commits of ever registered in this\n> > # project\n> > git submodulecheckout --find-versions > out.tmp\n> >\n> > # This reads the previous list and outputs a list of of all the commits\n> > # that contain . Function in_merge_bases(treeish, i&commit, 1)\n> > # can be of help here. Afterwards you have to prune all later commits\n> > # that contain earlier ones. I did this in find_first_merges(). I\n> > # suggest to refactor that code into a function so that you can use it.\n> > git submodulecheckout --find-closest -- < out.tmp > out2.tmp\n> >\n> > # And now we can search for the commit in the other submodule C\n> > git submodulecheckout --list-commits < out2.tmp > out3.tmp\n> >\n> > And if out3.tmp just contained one line we could checkout that one. I am\n> > still not sure in which command these options could go. Junio do you\n> > maybe have a suggestion? Since its all about submodules it would make\n> > sense to put it in 'git submodule' but thats already the script.\n> >\n> > Maybe a new 'git-submodule-tool' ?\n> \n> Before I wanted to name it submodule-checkout but I think I hade a\n> naming conflict issue with submodule... not sure if submodule-tool\n> will work...\n\nSince the submodule script might be obsoleted partly and get rewritten\nin C at some point I was thinking of this as a kind of intermediate\ninternal submodule helper tool.\n\nCheers Heiko\n"},{"id":"161720","messageId":"AANLkTimbzVd-fs=7KMHMVypb8=RJYah8BTGKQa4Yge1=@mail.gmail.com","threadId":"26340","inReplyTo":"20110214211317.GA50815@book.hvoigt.net","subject":"Re: Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository","fromName":"Julian Ibarz","fromEmail":"julian.ibarz@gmail.com","sentAt":"2011-02-20T01:15:08Z","receivedAt":"2011-02-20T01:15:08Z","isPatch":false,"sender":{"key":"julian.ibarz@gmail.com","avatar":null},"body":"On Mon, Feb 14, 2011 at 4:13 PM, Heiko Voigt wrote:\n> Hi,\n>\n> On Sun, Feb 13, 2011 at 01:59:09PM -0500, Julian Ibarz wrote:\n>> On Sun, Feb 13, 2011 at 8:30 AM, Heiko Voigt wrote:\n>> > Ok lets not be so hard:\n>> >\n>> > git checkout v1.7.2.3.msysgit.0\n>> > cd ..\n>> > git submodulecheckout --find-versions git > git-versions.txt\n>> > cd git\n>> > git submodulecheckout --find-closest < ../git-versions.txt\n>> >> 820fd48475eb72cdd4f2\n>> >\n>> > Close but not quite the right commit. See the output of git log:\n>> > 820fd48 Chomp CRLF before feeding to tar when building netinstaller.\n>> > 83e164c Avoid quoting environment variable values.\n>> > daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3\n>> >\n>> > Whats strange is that this commit did not even change the submodule.\n>>\n>> Well because it is _exactly_ the commit that point to the current\n>> submodule version you have checked out :) So it _is_ the good version.\n>> Which version were you thinking was good?\n>\n> Well I think the interface was/is still confusing me. Once you change to\n> one where I can specify the hash I want to search for I will give it\n> another try.\n>> > I think currently it does not make sense to implement the scripting\n>> > since the interface is not yet cleaned up enough. It should be possible\n>> > to specify a commit as parameter and the path should probably go after\n>> > that like the other commands do as well.\n>> >\n>> > The other issue is that we need to change the working directory. IMO,\n>> > everything should be possible to do from superproject. Have a look at\n>> > add_submodule_odb() in submodule.c it lets you load the database of a\n>> > submodule. This way you can run the --find-closest from the superproject.\n>>\n>> I don't think we want to do that. The usual scenario is:\n>>\n>> * you are in a submodule\n>> * you checkout a specific version\n>> * you want the meta-repo and side submodules to be updated accordingly\n>>\n>> And in this scenario at the beginning you are at the submodule\n>> directory, not the meta repository so... What do you think? Also even\n>> if in these low-level commands you need to change directory, if it is\n>> hided in an integration in the sh submodule script, it doesn't matter\n>> right?\n>\n> Well I think the interface should be useable by hand also. Lots of tools\n> in git were invented by plugging the tools together differently than the\n> original developer even had in his mind. So a nice \"do only one thing\n> but that very good\" kind of interface makes sense.\n>\n> I think a nice thing would be if you could stay in one directory and it\n> should not be too hard since we have add_submodule_odb(). Implementation\n> would be easier if we started this command from the supermodule since\n> searching for a supermodule from a submodule is still missing.\n>\n>> > So what I would be looking for is something like this:\n>> >\n>> > # This looks up all commits of ever registered in this\n>> > # project\n>> > git submodulecheckout --find-versions > out.tmp\n>> >\n>> > # This reads the previous list and outputs a list of of all the commits\n>> > # that contain . Function in_merge_bases(treeish, i&commit, 1)\n>> > # can be of help here. Afterwards you have to prune all later commits\n>> > # that contain earlier ones. I did this in find_first_merges(). I\n>> > # suggest to refactor that code into a function so that you can use it.\n>> > git submodulecheckout --find-closest -- < out.tmp > out2.tmp\n>> >\n>> > # And now we can search for the commit in the other submodule C\n>> > git submodulecheckout --list-commits < out2.tmp > out3.tmp\n>> >\n>> > And if out3.tmp just contained one line we could checkout that one. I am\n>> > still not sure in which command these options could go. Junio do you\n>> > maybe have a suggestion? Since its all about submodules it would make\n>> > sense to put it in 'git submodule' but thats already the script.\n>> >\n>> > Maybe a new 'git-submodule-tool' ?\n>>\n>> Before I wanted to name it submodule-checkout but I think I hade a\n>> naming conflict issue with submodule... not sure if submodule-tool\n>> will work...\n>\n> Since the submodule script might be obsoleted partly and get rewritten\n> in C at some point I was thinking of this as a kind of intermediate\n> internal submodule helper tool.\n>\n> Cheers Heiko\n>\n\nToday I have added the possibility to provide a hash to find-closest\nfeature. I have also implemented the two optimizations I was talking\nabout and now it is pretty fast. By the way I am using the binary tree\nfrom string-list.h. An example of execution:\n\ngit submodulecheckout --find-closest v1.7.3.1.msysgit.0 < ../git-versions.txt\n279f4c28cad4bd97dc06129118314b0a36f193db\n\n468fabbff85c10e5e226a2ea22699cd4186536f7\nfe61e4c51c9f3577fcb85951f72d3c65afce251d\n\nThe first commit is the closest referenced commit found starting from\nv1.7.3.1.msysgit.0 and then the last two are the commits in the parent\nrepository that reference this commit. If we integrate this in\ngit-submodule.sh, the script could take those hash and instead display\nthem + first line of commit message and the tags if there is one.\n\nAs for your third command --list-commits I don't think it matters. As\nsoon as the user has decided which commit in the parent repository he\nwants to checkout, then we just need to git submodule update\neverything except the submodule that helped us find it. Basically from\nthe example above. if we say that\n468fabbff85c10e5e226a2ea22699cd4186536f7 is the commit we were looking\nfor for msysgit then we can do git submodule update on everything\nexcept submodule git.\n\nNext on my TODO list:\n* Optimize find-versions using string-list\n* Run find-closest in the meta-repository instead\n* Implement a test example\n\nLet me know if I am missing something.\n\nBest regards,\nJulian\n"}]}