{"thread":{"id":"10944","subject":"Partial checkouts / submodules","startedAt":"2007-11-20T15:59:22Z","lastAt":"2007-11-21T00:04:11Z","messageCount":13,"participants":["Finn Arne Gangstad","Sven Verdoolaege","Daniel Barkalow","Steven Grimm","Sergei Organov","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60412","messageId":"20071120155922.GA6271@pvv.org","threadId":"10944","inReplyTo":null,"subject":"Partial checkouts / submodules","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2007-11-20T15:59:22Z","receivedAt":"2007-11-20T15:59:22Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"My use case it this: We have some huge projects (let's call them\nsupermodules) that are the only products we really release. Any change\ngoing into any of the submodules go in solely to modify the\nsuperproject, the submodules are not released on their own.\n\nWe cannot keep the supermodule with all its submodules in one git\nrepository for two reasons: Size & sharing. A 6GB+ repository is too\nbig to handle gracefully, and there are multiple superprojects sharing\nsome of the submodules. Our supermodules typically contains 50-250\nsubmodules. Usually it is sufficient to look at just a few of these\nsubmodules at the same time.\n\nI looked into the current git submodules to see if they support what I\nthink we need, but it seems like they do not really cut it (If I'm\nwrong about this, please educate me).\n\nWhat I want is this: \n\nSomewhere the following modules all exist:\n\nsupermodule/\n   submodule1\n   submodule2\n   submodule3\n    ...\n   submodule200\n\nYou pull the supermodule, and initialize random collection of\nsubmodules, e.g. locally you have:\n\nsupermodule/\n   submodule13\n   submodule71\n   submodule102\n\nNow I want this to behave as if it was a partial checkout of\n\"supermodule\" - i.e. I want _all_ operations in any of the submodules\nto act as if they happened in all the submodules (as if supermodule\nwas a single repository containing all the submodules directly).\n\nIf I do a change in submodule13, another change in submodule71 and yet\nanother change in submodule102, I want to be able to commit them all\nas ONE commit (obviously it will be 4 commits, 1 in each submodule and\none in the supermodule, but anyone looking at this in the context of\nthis supermodule should see it as one commit).\n\nIf I pull supermodule, I get updates to supermodule, submodule13,\nsubmodule71 and submodule102, but nothing else.\n\nIf I make a branch on submodule71, the branch is made in all submodules &\nthe supermodule.\n\nWith this setup it should be possible to handle supermodule as a\nnormal module with branches for each feature/topic/bugfix, and those\nfeatures being merged into other branches in a reasonable way. Does\nsomething like this look doable?\n\n- Finn Arne\n"},{"id":"60415","messageId":"20071120173350.GA2261MdfPADPa@greensroom.kotnet.org","threadId":"10944","inReplyTo":"20071120155922.GA6271@pvv.org","subject":"Re: Partial checkouts / submodules","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-11-20T17:33:50Z","receivedAt":"2007-11-20T17:33:50Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Tue, Nov 20, 2007 at 04:59:22PM +0100, Finn Arne Gangstad wrote:\n> I looked into the current git submodules to see if they support what I\n> think we need, but it seems like they do not really cut it (If I'm\n> wrong about this, please educate me).\n\nMaybe you could explain why you think they don't cut it.\n\n> You pull the supermodule, and initialize random collection of\n> submodules, e.g. locally you have:\n> \n> supermodule/\n>    submodule13\n>    submodule71\n>    submodule102\n\nJust \"submodule init\" and \"submodule update\" these submodules and\nit looks like you would get what you want...\n\n> If I make a branch on submodule71, the branch is made in all submodules &\n> the supermodule.\n\n... except this one.\nIt's not clear why you would even want this.\n\nskimo\n"},{"id":"60416","messageId":"Pine.LNX.4.64.0711201226320.32410@iabervon.org","threadId":"10944","inReplyTo":"20071120155922.GA6271@pvv.org","subject":"Re: Partial checkouts / submodules","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-20T18:03:46Z","receivedAt":"2007-11-20T18:03:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:\n\n> My use case it this: We have some huge projects (let's call them\n> supermodules) that are the only products we really release. Any change\n> going into any of the submodules go in solely to modify the\n> superproject, the submodules are not released on their own.\n> \n> We cannot keep the supermodule with all its submodules in one git\n> repository for two reasons: Size & sharing. A 6GB+ repository is too\n> big to handle gracefully, and there are multiple superprojects sharing\n> some of the submodules. Our supermodules typically contains 50-250\n> submodules. Usually it is sufficient to look at just a few of these\n> submodules at the same time.\n> \n> I looked into the current git submodules to see if they support what I\n> think we need, but it seems like they do not really cut it (If I'm\n> wrong about this, please educate me).\n> \n> What I want is this: \n> \n> Somewhere the following modules all exist:\n> \n> supermodule/\n>    submodule1\n>    submodule2\n>    submodule3\n>     ...\n>    submodule200\n> \n> You pull the supermodule, and initialize random collection of\n> submodules, e.g. locally you have:\n> \n> supermodule/\n>    submodule13\n>    submodule71\n>    submodule102\n> \n> Now I want this to behave as if it was a partial checkout of\n> \"supermodule\" - i.e. I want _all_ operations in any of the submodules\n> to act as if they happened in all the submodules (as if supermodule\n> was a single repository containing all the submodules directly).\n> \n> If I do a change in submodule13, another change in submodule71 and yet\n> another change in submodule102, I want to be able to commit them all\n> as ONE commit (obviously it will be 4 commits, 1 in each submodule and\n> one in the supermodule, but anyone looking at this in the context of\n> this supermodule should see it as one commit).\n\nThis has theoretical problems: it's going to be practically impossible, in \nmost cases, to write a commit message that describes changes in three \nsubmodules (which are sometimes used in the context of a different \nsupermodule) as well as the supermodule.\n\nOn the other hand, the supermodule commit is the one that's relevant in \nthe context of the supermodule, and that commit's message should describe \nthe set of changes as a whole.\n\nI think it should be possible and sufficient to have \"git commit\" able to \nrecursively start a \"git commit\" in submodules (where you'd write a \nseparate message suitable for exposure to other supermodules), so you'd \nhave to write 4 messages but only type one command line.\n\n> If I pull supermodule, I get updates to supermodule, submodule13,\n> submodule71 and submodule102, but nothing else.\n\nThis should work. Of course, if other people have made changes to parts of \nthe supermodule that you haven't checked out, your supermodule index will \nreflect those changes, so that supermodule commits you make aren't \nreverting or removing those submodules. But you won't fetch the contents \nof those submodules, and won't have them checked out. (Note, however, \nthat, if you pull from two places, each of which has changed the same \nsubmodule you don't have in a different way, you'll get a conflict you \ncan't resolve without getting the submodule yourself or getting somebody \nelse to merge them; git won't let you make commits which leave the \nsubmodule merge for somebody who cares)\n\n> If I make a branch on submodule71, the branch is made in all submodules &\n> the supermodule.\n\nI don't think this aspect has been worked out too carefully. I think the \nbranch is made only in the supermodule, but the submodules are attached to \nthe supermodule's index, rather than particularly using branches, and so, \nwhen the supermodule switches branches, the submodules should all follow, \nregardless of whether they have explicit branches.\n\n> With this setup it should be possible to handle supermodule as a\n> normal module with branches for each feature/topic/bugfix, and those\n> features being merged into other branches in a reasonable way. Does\n> something like this look doable?\n\nAFAIK, supermodules haven't gotten heavy enough use to work out all of the \ndetails of what should happen when the user does different things. I think \nit's all doable, but you may have to convince people to actually do it, \nand I don't think everything yet works the way you'd want.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"60419","messageId":"20071120181932.GA20705@pvv.org","threadId":"10944","inReplyTo":"20071120173350.GA2261MdfPADPa@greensroom.kotnet.org","subject":"Re: Partial checkouts / submodules","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2007-11-20T18:19:33Z","receivedAt":"2007-11-20T18:19:33Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Tue, Nov 20, 2007 at 06:33:50PM +0100, Sven Verdoolaege wrote:\n\n> Just \"submodule init\" and \"submodule update\" these submodules and\n> it looks like you would get what you want...\n> \n> > If I make a branch on submodule71, the branch is made in all submodules &\n> > the supermodule.\n> \n> ... except this one.\n> It's not clear why you would even want this.\n\nI'll try to boil this down to the simplest case possible. If\nsubmodules can do this I'll be really happy :)\n\nDeveloper A makes a change in submodule1 and in submodule2\nDeveloper B makes a change in submodule2 and in submodule3\n\nA and B don't know about eachother. They send their modifications\nsomewhere (push to a shared repository with a well chosen branch name,\nfor example), or send a mail \"please pull from my repo\" to the patch\nqueue manager.\n\nIt is absolutely crucial that for each developer, either both their\nmodifications go in, or none of them. Git should make picking only\none of their modifications hard.\n\nAlso - it would be very good if the history in the master repo would\nmatch the history in all developers' repositories (as the\nmodifications are merged in by the patch queue manager). I.e. - you\nshould see a \"gif support\" feature branch, see the commits on it, and\nfinally the merge.\n\n- Finn Arne\n"},{"id":"60423","messageId":"1AD9B065-647B-4672-B6B0-8D4447960913@midwinter.com","threadId":"10944","inReplyTo":"Pine.LNX.4.64.0711201226320.32410@iabervon.org","subject":"Re: Partial checkouts / submodules","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-11-20T18:26:43Z","receivedAt":"2007-11-20T18:26:43Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Nov 20, 2007, at 10:03 AM, Daniel Barkalow wrote:\n> This has theoretical problems: it's going to be practically  \n> impossible, in\n> most cases, to write a commit message that describes changes in three\n> submodules (which are sometimes used in the context of a different\n> supermodule) as well as the supermodule.\n\nI got the impression from his email that there *are* no other  \nsupermodules. The submodules are submodules purely to reduce the  \namount of data people have to transfer around, not because they're  \nlogically distinct from the parent.\n\nSomething like \"Fix bug #10391 by closing the data file before  \nlaunching the GUI\" or something like that would be just as valid a  \ncommit comment in the submodules here as it would be in the  \nsupermodules.\n\nSounds like what he wants is actually partial checkout, but since git  \ndoesn't (yet) support that, he's emulating it as best he can using  \nsubmodules.\n\n> I think it should be possible and sufficient to have \"git commit\"  \n> able to\n> recursively start a \"git commit\" in submodules (where you'd write a\n> separate message suitable for exposure to other supermodules), so  \n> you'd\n> have to write 4 messages but only type one command line.\n\nIf the message in the submodule defaulted to the one from the  \nsupermodule, and there was a way to just accept it without popping up  \nan editor N times, this might solve his problem.\n\n-Steve\n"},{"id":"60426","messageId":"Pine.LNX.4.64.0711201329490.32410@iabervon.org","threadId":"10944","inReplyTo":"1AD9B065-647B-4672-B6B0-8D4447960913@midwinter.com","subject":"Re: Partial checkouts / submodules","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-20T18:36:02Z","receivedAt":"2007-11-20T18:36:02Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Nov 2007, Steven Grimm wrote:\n\n> On Nov 20, 2007, at 10:03 AM, Daniel Barkalow wrote:\n> >This has theoretical problems: it's going to be practically impossible, in\n> >most cases, to write a commit message that describes changes in three\n> >submodules (which are sometimes used in the context of a different\n> >supermodule) as well as the supermodule.\n> \n> I got the impression from his email that there *are* no other supermodules.\n> The submodules are submodules purely to reduce the amount of data people have\n> to transfer around, not because they're logically distinct from the parent.\n\nHe said:\n\n\"there are multiple superprojects sharing some of the submodules.\"\n\nGetting the effect of partial checkouts was the first-listed reason, but \nnot the only one. The submodules don't make sense except in the context of \nsome supermodule, but there are multiple contexts they each appear in.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"60427","messageId":"20071120184227.GB2261MdfPADPa@greensroom.kotnet.org","threadId":"10944","inReplyTo":"20071120181932.GA20705@pvv.org","subject":"Re: Partial checkouts / submodules","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-11-20T18:42:27Z","receivedAt":"2007-11-20T18:42:27Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Tue, Nov 20, 2007 at 07:19:33PM +0100, Finn Arne Gangstad wrote:\n> On Tue, Nov 20, 2007 at 06:33:50PM +0100, Sven Verdoolaege wrote:\n> \n> > Just \"submodule init\" and \"submodule update\" these submodules and\n> > it looks like you would get what you want...\n> > \n> > > If I make a branch on submodule71, the branch is made in all submodules &\n> > > the supermodule.\n> > \n> > ... except this one.\n> > It's not clear why you would even want this.\n> \n> I'll try to boil this down to the simplest case possible. If\n> submodules can do this I'll be really happy :)\n> \n> Developer A makes a change in submodule1 and in submodule2\n> Developer B makes a change in submodule2 and in submodule3\n\nI'm assuming that A and B also make a commit to the supermodule\nincorporating their changes to the submodules (as in your\noriginal message).\n\n> A and B don't know about eachother. They send their modifications\n> somewhere (push to a shared repository with a well chosen branch name,\n> for example), or send a mail \"please pull from my repo\" to the patch\n> queue manager.\n\nThe commit A made to the superproject contains his changes\nto the submodule, so if someone pulls this superproject commit,\nshe'll get the submodule changes too.\n(Although she may choose not to have some or all of these\nsubmodules checked out.)\n\n> Also - it would be very good if the history in the master repo would\n> match the history in all developers' repositories (as the\n> modifications are merged in by the patch queue manager). I.e. - you\n> should see a \"gif support\" feature branch, see the commits on it, and\n> finally the merge.\n\nYou can't change the history in git. [*1]\n\nIt's still not clear why you would want new branches to be created\nin other modules when you create a new branch in some module.\n\nskimo\n\n[*1] There are tools that allow you to create a new history based\non an old history, but it will be a different history.\n"},{"id":"60429","messageId":"87ir3wzqzj.fsf@osv.gnss.ru","threadId":"10944","inReplyTo":"1AD9B065-647B-4672-B6B0-8D4447960913@midwinter.com","subject":"Re: Partial checkouts / submodules","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-20T18:55:28Z","receivedAt":"2007-11-20T18:55:28Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Steven Grimm <koreth@midwinter.com> writes:\n\n> On Nov 20, 2007, at 10:03 AM, Daniel Barkalow wrote:\n>> This has theoretical problems: it's going to be practically\n>> impossible, in\n>> most cases, to write a commit message that describes changes in three\n>> submodules (which are sometimes used in the context of a different\n>> supermodule) as well as the supermodule.\n>\n> I got the impression from his email that there *are* no other\n> supermodules. The submodules are submodules purely to reduce the\n> amount of data people have to transfer around, not because they're\n> logically distinct from the parent.\n\nI got the same impression, and then I wonder if the next logical thing\nthe OP will need is, say, support for content moves between\nsubmodules. Somehow I doubt git will ever support that.\n\n-- \nSergei.\n"},{"id":"60430","messageId":"Pine.LNX.4.64.0711201336530.32410@iabervon.org","threadId":"10944","inReplyTo":"20071120181932.GA20705@pvv.org","subject":"Re: Partial checkouts / submodules","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-20T18:59:41Z","receivedAt":"2007-11-20T18:59:41Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:\n\n> On Tue, Nov 20, 2007 at 06:33:50PM +0100, Sven Verdoolaege wrote:\n> \n> > Just \"submodule init\" and \"submodule update\" these submodules and\n> > it looks like you would get what you want...\n> > \n> > > If I make a branch on submodule71, the branch is made in all submodules &\n> > > the supermodule.\n> > \n> > ... except this one.\n> > It's not clear why you would even want this.\n> \n> I'll try to boil this down to the simplest case possible. If\n> submodules can do this I'll be really happy :)\n> \n> Developer A makes a change in submodule1 and in submodule2\n> Developer B makes a change in submodule2 and in submodule3\n> \n> A and B don't know about eachother. They send their modifications\n> somewhere (push to a shared repository with a well chosen branch name,\n> for example), or send a mail \"please pull from my repo\" to the patch\n> queue manager.\n> \n> It is absolutely crucial that for each developer, either both their\n> modifications go in, or none of them. Git should make picking only\n> one of their modifications hard.\n\nThis is the case; if developer A changes 2 from 2-O to 2-A, and developer \nB changes 2 from 2-O to 2-B, merging both supermodule commits gets a \nconflict, which requires a merge in submodule 2 before the supermodule \nmerge can be committed.\n\nOn the other hand, 3-B will sort of enter the history of submodule 3 \nwithout the submodule 2 merge getting done; however, there's no way for \nanybody to find it if it's not referenced by any supermodule commit yet \nand people don't look at the individual histories of submodules.\n\nOne thing that might be an issue is that, if developer A of supermodule I \nmakes a commit that changes submodule 1 and submodule 2, and developer B \non supermodule II decides to merge supermodule I's submodule 1, and \nsupermodule II also includes submodule 2, but developer B doesn't care \nabout it, supermodule II could end up with only half of developer A's \nchange.\n\n> Also - it would be very good if the history in the master repo would\n> match the history in all developers' repositories (as the\n> modifications are merged in by the patch queue manager). I.e. - you\n> should see a \"gif support\" feature branch, see the commits on it, and\n> finally the merge.\n\nThis is independant of submodule support, and depends on the patch queue \nmanager's policy. In some cases, it's desirable to simplify the history of \nthe feature branch when it's being merged into the master repo, so that \nthe master repo gets an idealized version of the feature branch (i.e., \nbugs introduced early in the development of the branch and fixed later, \nbut never affected the master repo, are not introduced in the first place; \nalso, the historical accident of the work on the topic being started \nbefore other features but completed after them can be smoothed over, with \nthe resolution of merge conflicts distributed back to the sites where the \nsecond set of changes was made). If the patch queue manager does this sort \nof thing, the master repo's history will be different from the feature \nbranch's history as it appeared to the developers at the time, but the \nfeature branch also generally goes away at this point anyway, so it \ndoesn't matter too much.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"60432","messageId":"Pine.LNX.4.64.0711201401090.32410@iabervon.org","threadId":"10944","inReplyTo":"87ir3wzqzj.fsf@osv.gnss.ru","subject":"Re: Partial checkouts / submodules","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-20T19:15:43Z","receivedAt":"2007-11-20T19:15:43Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Nov 2007, Sergei Organov wrote:\n\n> I got the same impression, and then I wonder if the next logical thing\n> the OP will need is, say, support for content moves between\n> submodules. Somehow I doubt git will ever support that.\n\nI don't see why not. If you tell the diff engine to look for content \nmoves, and you tell it to descend into submodules that you have, and you \nhave both ends of the content move, and you're looking at a supermodule \ncommit where such a content move happened, it should show it.\n\nIf any of these aren't true (and I don't think we have a \"descend into \navailable submodules\" option currently), you won't see it as a content \nmove, but you wouldn't expect to; you don't want to get a diff that says: \n\"move from (path you don't have) to (path you have)\", with the diff \nshowing changes in the process, when you didn't have the original.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"60434","messageId":"20071120192231.GA23240@pvv.org","threadId":"10944","inReplyTo":"Pine.LNX.4.64.0711201336530.32410@iabervon.org","subject":"Re: Partial checkouts / submodules","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2007-11-20T19:22:32Z","receivedAt":"2007-11-20T19:22:32Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Tue, Nov 20, 2007 at 01:59:41PM -0500, Daniel Barkalow wrote:\n> On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:\n> \n> > I'll try to boil this down to the simplest case possible. If\n> > submodules can do this I'll be really happy :)\n> > \n> > Developer A makes a change in submodule1 and in submodule2\n> > Developer B makes a change in submodule2 and in submodule3\n> > \n> > A and B don't know about eachother. They send their modifications\n> > somewhere (push to a shared repository with a well chosen branch name,\n> > for example), or send a mail \"please pull from my repo\" to the patch\n> > queue manager.\n> > \n> > It is absolutely crucial that for each developer, either both their\n> > modifications go in, or none of them. Git should make picking only\n> > one of their modifications hard.\n> \n> This is the case; if developer A changes 2 from 2-O to 2-A, and developer \n> B changes 2 from 2-O to 2-B, merging both supermodule commits gets a \n> conflict, which requires a merge in submodule 2 before the supermodule \n> merge can be committed.\n\nAnd this is partly why I wanted to branch all the involved modules: In\n~99% of the cases, 2-A and 2-B modify different files, or at least\nwildly different parts of the same file, so the merge should be\ntrivial/automatic. Therefore, the supermodule merge should also be a\ntrivial/automatic merge - but it isn't, is it?\n\n- Finn Arne\n"},{"id":"60438","messageId":"Pine.LNX.4.64.0711201508590.32410@iabervon.org","threadId":"10944","inReplyTo":"20071120192231.GA23240@pvv.org","subject":"Re: Partial checkouts / submodules","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-20T20:18:14Z","receivedAt":"2007-11-20T20:18:14Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:\n\n> On Tue, Nov 20, 2007 at 01:59:41PM -0500, Daniel Barkalow wrote:\n> > On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:\n> > \n> > > I'll try to boil this down to the simplest case possible. If\n> > > submodules can do this I'll be really happy :)\n> > > \n> > > Developer A makes a change in submodule1 and in submodule2\n> > > Developer B makes a change in submodule2 and in submodule3\n> > > \n> > > A and B don't know about eachother. They send their modifications\n> > > somewhere (push to a shared repository with a well chosen branch name,\n> > > for example), or send a mail \"please pull from my repo\" to the patch\n> > > queue manager.\n> > > \n> > > It is absolutely crucial that for each developer, either both their\n> > > modifications go in, or none of them. Git should make picking only\n> > > one of their modifications hard.\n> > \n> > This is the case; if developer A changes 2 from 2-O to 2-A, and developer \n> > B changes 2 from 2-O to 2-B, merging both supermodule commits gets a \n> > conflict, which requires a merge in submodule 2 before the supermodule \n> > merge can be committed.\n> \n> And this is partly why I wanted to branch all the involved modules: In\n> ~99% of the cases, 2-A and 2-B modify different files, or at least\n> wildly different parts of the same file, so the merge should be\n> trivial/automatic. Therefore, the supermodule merge should also be a\n> trivial/automatic merge - but it isn't, is it?\n\nIt's an automatic merge if you've got the submodule; if you don't have the \nsubmodule, you can't tell that the merge would be trivial, because you \ncan't even see the order of the history in the submodule, let alone which \nfiles change and how. This just means that the patch queue manager is \ngoing to have to have all of the submodules, which is probably reasonable \nif the patch queue manager is responsible for making sure that the \ncombination works.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"60446","messageId":"fhvslp$9jr$1@ger.gmane.org","threadId":"10944","inReplyTo":"20071120181932.GA20705@pvv.org","subject":"Re: Partial checkouts / submodules","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-21T00:04:11Z","receivedAt":"2007-11-21T00:04:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Finn Arne Gangstad wrote:\n\n> I'll try to boil this down to the simplest case possible. If\n> submodules can do this I'll be really happy :)\n> \n> Developer A makes a change in submodule1 and in submodule2\n> Developer B makes a change in submodule2 and in submodule3\n\nAnd committed changes to submodules and supermodule, I guess,\nso developer A has submodule1 in state 1a, submodule2 in state 2a.\nsumbodule3 in state 3, and supermodule in state [1a, 2a, 3], while\ndeveloper B has submodule1 in state 1, submodule2 in state 2b, \nsubmodule3 in state 3b, and supermodule in state [1, 2b, 3b].\n \n> A and B don't know about eachother. They send their modifications\n> somewhere (push to a shared repository with a well chosen branch name,\n> for example), or send a mail \"please pull from my repo\" to the patch\n> queue manager.\n> \n> It is absolutely crucial that for each developer, either both their\n> modifications go in, or none of them. Git should make picking only\n> one of their modifications hard.\n\nGit treats submodules as whole, so merging A and B supermodules will result\nin [1a, CONFLICT(2a/2b), 3b]. 2a/2b _might_ resolve cleanly to 2ab,\nbut this requires submodule2 to be checked out. I'm not sure what git does\nin such case, but it is not much different from the case when both sides A\nand B modified the same file, but it merges on file-level cleanly; here we\nhave subprojects and tree-level in-subproject clean merge.\n\n[...]\n\nBy the way, submodules in supermodule should be thought as on \n'detached HEAD'.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}