{"thread":{"id":"9564","subject":"How do I manage this setup with git-svn and/or git remotes?","startedAt":"2007-08-17T17:24:14Z","lastAt":"2007-08-19T16:04:46Z","messageCount":10,"participants":["David Kastrup","Linus Torvalds","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50943","messageId":"86y7gaxef5.fsf@lola.quinscape.zz","threadId":"9564","inReplyTo":null,"subject":"How do I manage this setup with git-svn and/or git remotes?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-17T17:24:14Z","receivedAt":"2007-08-17T17:24:14Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nI have a Subversion repository which contains the following:\n\nhttps://repo.here/svn/dsp/{trunk,tags,branches}\nand\nhttps://repo.here/svn/projects/great/{trunk/tags/branches}\n\nI have those currently checked out into separate git repositories.\nHowever,\n\nhttps://repo.here/svn/projects/great/{trunk/tags/branches}\n\ncontain a subdirectory dsp that has been copied via Subversion from\nthe main dsp trunk. Subsequently this copy and the original dsp have\nprogressed.\n\nNow is there any chance to set up a git structure that will me allow\nto let _git_ perform merges between the standalone dsp project and the\npart that has started off as a copy of it in a subdirectory from\nprojects/great, so that I have a merge history in my git mirror?\n\nOr is basically the only thing I can do to create selective patches\nand apply them, thus not tracking the merges?\n\n-- \nDavid Kastrup\n"},{"id":"50949","messageId":"alpine.LFD.0.999.0708171042570.30176@woody.linux-foundation.org","threadId":"9564","inReplyTo":"86y7gaxef5.fsf@lola.quinscape.zz","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-17T17:56:25Z","receivedAt":"2007-08-17T17:56:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 17 Aug 2007, David Kastrup wrote:\n> \n> Now is there any chance to set up a git structure that will me allow\n> to let _git_ perform merges between the standalone dsp project and the\n> part that has started off as a copy of it in a subdirectory from\n> projects/great, so that I have a merge history in my git mirror?\n\nYes. That's what git \"submodule\" support is all about. You could create \nthat \"dsp\" project as its own git project, and then include it within the \nbigger project as a submodule. Then, that \"dsp\" thing is really a totally \nindependent git project in its own right, with git support for just \n\"tying\" it into the superproject.\n\nA few words of caution:\n\n - while the low-level core submodule support has been around for a while\n now, the actual \"porcelain\" level helper stuff is new to 1.5.3 (which \n is unreleased, so you'd have to use the current git \"master\" branch, of \n course)\n\n - submodules are (very much by design) meant to be git projects in their\n own right, and kept separate. That very explicit separation means that \n you will *see* it as a separate project, and you may decide that it's \n not worth the extra setup/complexity if the \"dsp\" thing just isn't big \n enough or the merge complexity just isn't worth the effort.\n\n - not very many people use it. The msysgit people seem to be using it,\n and Andy Parkins has been using it for a while (and seems happy), but I \n think you basically end up having less documentation and somewhat less \n support for it (and it doesn't get the same kind of testing that the \n \"basic\" git behaviours get).\n\nAnother alternative is to do what git has long done with \"gitk\": you can \nmaintain a separate project and just merge it directly into another git \nproject, and it works fine that way, but it gets impossible to merge back \nand forth between the two projects (you can only merge one way: make all \nthe major changes in the \"dsp\" project, and then you can just merge it \ninto the project that uses it (but if you fix things in the bigger \nproject, you can't merge the fixes back, you'll have to export the fixes \nas patches and do them in the \"dsp\" tree).\n\n\t\t\tLinus\n"},{"id":"50950","messageId":"86d4xmxbjf.fsf@lola.quinscape.zz","threadId":"9564","inReplyTo":"alpine.LFD.0.999.0708171042570.30176@woody.linux-foundation.org","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-17T18:26:28Z","receivedAt":"2007-08-17T18:26:28Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 17 Aug 2007, David Kastrup wrote:\n>> \n>> Now is there any chance to set up a git structure that will me\n>> allow to let _git_ perform merges between the standalone dsp\n>> project and the part that has started off as a copy of it in a\n>> subdirectory from projects/great, so that I have a merge history in\n>> my git mirror?\n>\n> Yes. That's what git \"submodule\" support is all about. You could\n> create that \"dsp\" project as its own git project, and then include\n> it within the bigger project as a submodule. Then, that \"dsp\" thing\n> is really a totally independent git project in its own right, with\n> git support for just \"tying\" it into the superproject.\n\nBut it isn't an independent git project: the superproject has its\n_own_ copy of dsp, with its _own_ specific commits and fixes that are\nnot supposed to ever end up in the dsp \"mothership\". There are\nsometimes cross merges, but the stuff in the \"dsp\" subdirectory of\n\"great\" is maintained completely together with the branches of\n\"great\": tags, branches and all.\n\nBut I would like to be able to merge this _subdirectory_ with branches\nfrom the \"mothership\" dsp from which it was originally copied.\n\nWith Subversion, I can actually merge files in different projects of\nthe repository even when they are in different directory levels. Of\ncourse, since Subversion does not track any merge info, that is not an\naccomplishment.\n\nI don't see quite how this would work with submodules, and in\nparticular not when git-svn gets involved as well.\n\n> A few words of caution:\n>\n> - while the low-level core submodule support has been around for a\n> while now, the actual \"porcelain\" level helper stuff is new to\n> 1.5.3 (which is unreleased, so you'd have to use the current git\n> \"master\" branch, of course)\n\nHave to for a variety of reasons, anyway.\n\n> - submodules are (very much by design) meant to be git projects in\n> their own right, and kept separate. That very explicit separation\n> means that you will *see* it as a separate project, and you may\n> decide that it's not worth the extra setup/complexity if the \"dsp\"\n> thing just isn't big enough or the merge complexity just isn't\n> worth the effort.\n\nAnd that is the problem here: in this case it does not make sense to\nsee it as a separate project, and in particular, it needs to be in\nsynch with the tags/branches of the superproject, and particularly\nwhile I am using git-svn.\n\n> Another alternative is to do what git has long done with \"gitk\": you\n> can maintain a separate project and just merge it directly into\n> another git project, and it works fine that way, but it gets\n> impossible to merge back and forth between the two projects (you can\n> only merge one way: make all the major changes in the \"dsp\" project,\n> and then you can just merge it into the project that uses it (but if\n> you fix things in the bigger project, you can't merge the fixes\n> back, you'll have to export the fixes as patches and do them in the\n> \"dsp\" tree).\n\nWell, that would be at least quite handy for propagating upstream dsp\nfixes into project/great. How do I merge one project into a\n_subdirectory_ of another one?\n\n-- \nDavid Kastrup\n"},{"id":"50952","messageId":"alpine.LFD.0.999.0708171142510.30176@woody.linux-foundation.org","threadId":"9564","inReplyTo":"86d4xmxbjf.fsf@lola.quinscape.zz","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-17T18:53:06Z","receivedAt":"2007-08-17T18:53:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 17 Aug 2007, David Kastrup wrote:\n> \n> But it isn't an independent git project: the superproject has its\n> _own_ copy of dsp, with its _own_ specific commits and fixes that are\n> not supposed to ever end up in the dsp \"mothership\". \n\nSure. And that's different from any git \"branch\" exactly how?\n\nSo you'd have different branches in the superproject - the way you always \nhave when you have two copies of a git project. And then you merge between \nthe two at will.\n\n> With Subversion, I can actually merge files in different projects of\n> the repository even when they are in different directory levels. Of\n> course, since Subversion does not track any merge info, that is not an\n> accomplishment.\n\nRight. Git can do that too. It's called \"patches\".\n\n> And that is the problem here: in this case it does not make sense to\n> see it as a separate project, and in particular, it needs to be in\n> synch with the tags/branches of the superproject, and particularly\n> while I am using git-svn.\n\nI do agree that the \"git svn\" interaction may end up making it unworkable, \nif only because git-svn simply doesn't know/understand about submodules. \nBut the submodule *would* be well-specified by the tags and branches in \nthe superproject, so that shouldn't be a problem in itself.\n\n> > Another alternative is to do what git has long done with \"gitk\": you\n> > can maintain a separate project and just merge it directly into\n> > another git project, and it works fine that way, but it gets\n> > impossible to merge back and forth between the two projects (you can\n> > only merge one way: make all the major changes in the \"dsp\" project,\n> > and then you can just merge it into the project that uses it (but if\n> > you fix things in the bigger project, you can't merge the fixes\n> > back, you'll have to export the fixes as patches and do them in the\n> > \"dsp\" tree).\n> \n> Well, that would be at least quite handy for propagating upstream dsp\n> fixes into project/great. How do I merge one project into a\n> _subdirectory_ of another one?\n\nThere's a special \"subtree\" merge that does exactly that: it basically is \nthe normal recursive merge, except it merges into a subtree. I think \nthat's how Junio does the \"git-gui\" merges. Junio?\n\n\t\t\tLinus\n"},{"id":"50954","messageId":"85abspyisp.fsf@lola.goethe.zz","threadId":"9564","inReplyTo":"alpine.LFD.0.999.0708171142510.30176@woody.linux-foundation.org","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-17T21:04:22Z","receivedAt":"2007-08-17T21:04:22Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 17 Aug 2007, David Kastrup wrote:\n>> \n>> But it isn't an independent git project: the superproject has its\n>> _own_ copy of dsp, with its _own_ specific commits and fixes that are\n>> not supposed to ever end up in the dsp \"mothership\". \n>\n> Sure. And that's different from any git \"branch\" exactly how?\n\nDifferent directory structure. That can't easily be rectified as far\nas I can see since the stuff still needs to get synched with\nSubversion.\n\n> So you'd have different branches in the superproject - the way you\n> always have when you have two copies of a git project. And then you\n> merge between the two at will.\n\nThe problem is the different location: root vs subdirectory.\n\n>> With Subversion, I can actually merge files in different projects\n>> of the repository even when they are in different directory levels.\n>> Of course, since Subversion does not track any merge info, that is\n>> not an accomplishment.\n>\n> Right. Git can do that too. It's called \"patches\".\n\nYup. The question is just whether it is possible to do better than\nthat.\n\n>> Well, that would be at least quite handy for propagating upstream\n>> dsp fixes into project/great. How do I merge one project into a\n>> _subdirectory_ of another one?\n>\n> There's a special \"subtree\" merge that does exactly that: it\n> basically is the normal recursive merge, except it merges into a\n> subtree.\n\nSounds like just the thing.\n\n> I think that's how Junio does the \"git-gui\" merges. Junio?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"50956","messageId":"7vvebdg8r5.fsf@gitster.siamese.dyndns.org","threadId":"9564","inReplyTo":"alpine.LFD.0.999.0708171142510.30176@woody.linux-foundation.org","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-17T21:18:38Z","receivedAt":"2007-08-17T21:18:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 17 Aug 2007, David Kastrup wrote:\n>> \n>> But it isn't an independent git project: the superproject has its\n>> _own_ copy of dsp, with its _own_ specific commits and fixes that are\n>> not supposed to ever end up in the dsp \"mothership\". \n>\n> Sure. And that's different from any git \"branch\" exactly how?\n>\n> So you'd have different branches in the superproject - the way you always \n> have when you have two copies of a git project. And then you merge between \n> the two at will.\n\nMy reading of the project David is talking about is that its dsp\nproject which is a \"subproject\" part gets non generic commits\nwithin the context of the superproject --- which means (1) you\nwould have branches in the subproject not superproject, and (2)\nonce you did that, the subproject is not really a subproject\nanymore, as you cannot merge that back to the standalone dsp\nproject without dragging the non-generic bits along with it.\n\n> There's a special \"subtree\" merge that does exactly that: it basically is \n> the normal recursive merge, except it merges into a subtree. I think \n> that's how Junio does the \"git-gui\" merges. Junio?\n\nYes. It has exactly the same semantics and limitations with the\ngitk merge, but just merges into a sub directory. Shawn cannot\neasily pull the changes done inside git.git repository back to\ngit-gui.git proper.\n"},{"id":"50958","messageId":"85mywpx2wl.fsf@lola.goethe.zz","threadId":"9564","inReplyTo":"7vvebdg8r5.fsf@gitster.siamese.dyndns.org","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-17T21:32:58Z","receivedAt":"2007-08-17T21:32:58Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> On Fri, 17 Aug 2007, David Kastrup wrote:\n>>> \n>>> But it isn't an independent git project: the superproject has its\n>>> _own_ copy of dsp, with its _own_ specific commits and fixes that are\n>>> not supposed to ever end up in the dsp \"mothership\". \n>>\n>> Sure. And that's different from any git \"branch\" exactly how?\n>>\n>> So you'd have different branches in the superproject - the way you always \n>> have when you have two copies of a git project. And then you merge between \n>> the two at will.\n>\n> My reading of the project David is talking about is that its dsp\n> project which is a \"subproject\" part gets non generic commits within\n> the context of the superproject --- which means (1) you would have\n> branches in the subproject not superproject, and (2) once you did\n> that, the subproject is not really a subproject anymore, as you\n> cannot merge that back to the standalone dsp project without\n> dragging the non-generic bits along with it.\n\nOk, I should perhaps should not make things harder than they are: the\nsuperprojects, being particular to one customer each, don't really\nbranch (except that git-svn makes a git branch from every Subversion\ntag). The subproject is the one that has considerable branching and\nmerges. What usually gets pulled into the superproject is a copy of a\nstable subproject branch. Once this copy is in, only fixes (from the\nstable branch) or features (from the development branch) that the\ncustomer definitely needs are merged into the superproject. While\nthere might happen some subproject work in the customer branch, this\nmostly happens during bugfixing for the customer, and the changes are\ntypically pulled back into the subproject proper at some point of\ntime. Inside of the subproject tree, there is really no superproject\n_development_ going on.\n\n>> There's a special \"subtree\" merge that does exactly that: it\n>> basically is the normal recursive merge, except it merges into a\n>> subtree. I think that's how Junio does the \"git-gui\" merges. Junio?\n>\n> Yes. It has exactly the same semantics and limitations with the\n> gitk merge, but just merges into a sub directory. Shawn cannot\n> easily pull the changes done inside git.git repository back to\n> git-gui.git proper.\n\nWell, the other direction would be the most important one: merging or\ncherrypicking selected changes in the subproject branches into the\nsuperproject copy of the subproject.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"50973","messageId":"85643dwcb8.fsf@lola.goethe.zz","threadId":"9564","inReplyTo":"85mywpx2wl.fsf@lola.goethe.zz","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-18T07:07:23Z","receivedAt":"2007-08-18T07:07:23Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Kastrup writes:\n\n> Junio C Hamano writes:\n>>\n>> My reading of the project David is talking about is that its dsp\n>> project which is a \"subproject\" part gets non generic commits within\n>> the context of the superproject --- which means (1) you would have\n>> branches in the subproject not superproject, and (2) once you did\n>> that, the subproject is not really a subproject anymore, as you\n>> cannot merge that back to the standalone dsp project without\n>> dragging the non-generic bits along with it.\n>\n> Ok, I should perhaps should not make things harder than they are: the\n> superprojects, being particular to one customer each, don't really\n> branch (except that git-svn makes a git branch from every Subversion\n> tag). The subproject is the one that has considerable branching and\n> merges. What usually gets pulled into the superproject is a copy of a\n> stable subproject branch. Once this copy is in, only fixes (from the\n> stable branch) or features (from the development branch) that the\n> customer definitely needs are merged into the superproject. While\n> there might happen some subproject work in the customer branch, this\n> mostly happens during bugfixing for the customer, and the changes are\n> typically pulled back into the subproject proper at some point of\n> time. Inside of the subproject tree, there is really no superproject\n> _development_ going on.\n\nI think I got it. My mistake was focusing all the time what I could\ndo with the git repository of \"great\" to facilitate two-way merges.\n\nInstead I need to import great/trunk/dsp into a remote branch in my\n_dsp_ git repository. Since for git-svn, every Subversion directory\nis as good to import as any other (there is no concept of a worktree\nroot in the repository) that should be all it takes.\n\nI'll need to use the dsp repository when doing merge work, but apart\nfrom that, I can work in the great repository r/w even while in the\ndsp subdirectory.\n\nIf one could tell git in a remote section to\nfetch/consider/synchronize/push just a subdirectory as the repo root,\nthen the same setup for bidirectional merges could be made to work\nwith projects like gitk. Though I am fuzzy about the merge\ninformation... But that is a problem when pushing merges with private\nbranches, anyway, isn't it?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"50988","messageId":"fa7vrd$afs$1@sea.gmane.org","threadId":"9564","inReplyTo":"86d4xmxbjf.fsf@lola.quinscape.zz","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-18T23:37:21Z","receivedAt":"2007-08-18T23:37:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Kastrup wrote:\n\n> Linus Torvalds writes:\n> \n>> On Fri, 17 Aug 2007, David Kastrup wrote:\n>>> \n>>> Now is there any chance to set up a git structure that will me\n>>> allow to let _git_ perform merges between the standalone dsp\n>>> project and the part that has started off as a copy of it in a\n>>> subdirectory from projects/great, so that I have a merge history in\n>>> my git mirror?\n>>\n>> Yes. That's what git \"submodule\" support is all about.  You could\n>> create that \"dsp\" project as its own git project, and then include\n>> it within the bigger project as a submodule. Then, that \"dsp\" thing\n>> is really a totally independent git project in its own right, with\n>> git support for just \"tying\" it into the superproject.\n> \n> But it isn't an independent git project: the superproject has its\n> _own_ copy of dsp, with its _own_ specific commits and fixes that are\n> not supposed to ever end up in the dsp \"mothership\".  There are\n> sometimes cross merges, but the stuff in the \"dsp\" subdirectory of\n> \"great\" is maintained completely together with the branches of\n> \"great\": tags, branches and all.\n\nIndependent git project means independent clone of \"dsp\" repository,\nperhaps a fork of \"dsp\" repository with some (superproject) specific\ncommits. Which is attached as subritectory of superproject.\n \n> But I would like to be able to merge this _subdirectory_ with branches\n> from the \"mothership\" dsp from which it was originally copied.\n\nYou would be able to, both from \"mothership\" to \"submodule\", and from\n\"submodule\" (perhaps only some selected commits on 'maint' branch) to\n\"mothership\".\n\nPutting files of \"dsp\" project directly in superproject and merging from\n\"mothership\" using 'subtree' merge strategy as mentioned allows only for\none direction (well, except for sending patches).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"51000","messageId":"853ayftsrl.fsf@lola.goethe.zz","threadId":"9564","inReplyTo":"fa7vrd$afs$1@sea.gmane.org","subject":"Re: How do I manage this setup with git-svn and/or git remotes?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-19T16:04:46Z","receivedAt":"2007-08-19T16:04:46Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jakub Narebski writes:\n\n> David Kastrup wrote:\n>\n>> Linus Torvalds writes:\n>> \n>>> On Fri, 17 Aug 2007, David Kastrup wrote:\n>>>> \n>>>> Now is there any chance to set up a git structure that will me\n>>>> allow to let _git_ perform merges between the standalone dsp\n>>>> project and the part that has started off as a copy of it in a\n>>>> subdirectory from projects/great, so that I have a merge history in\n>>>> my git mirror?\n>>>\n>>> Yes. That's what git \"submodule\" support is all about.  You could\n>>> create that \"dsp\" project as its own git project, and then include\n>>> it within the bigger project as a submodule. Then, that \"dsp\" thing\n>>> is really a totally independent git project in its own right, with\n>>> git support for just \"tying\" it into the superproject.\n>> \n>> But it isn't an independent git project: the superproject has its\n>> _own_ copy of dsp, with its _own_ specific commits and fixes that are\n>> not supposed to ever end up in the dsp \"mothership\".  There are\n>> sometimes cross merges, but the stuff in the \"dsp\" subdirectory of\n>> \"great\" is maintained completely together with the branches of\n>> \"great\": tags, branches and all.\n>\n> Independent git project means independent clone of \"dsp\" repository,\n> perhaps a fork of \"dsp\" repository with some (superproject) specific\n> commits. Which is attached as subritectory of superproject.\n\nWell, the point I was trying to make is that as a subdirectory of the\nsuperproject (in Subversion), the tagging and branching structure is\nsupposed to follow that of the superproject. I don't understand\nsubmodules well enough to see how much this is the case.\n\nTo be fair: merging will only happen on the trunk of the superproject,\nbut possibly with different branches of the dsp project. So this is\nlikely not going to be much of an issue.\n\nOn the other hand, it is unclear what git-svn would think about that\nsort of setup. Since a submodule setup would imply creating\nappropriate branches in the dsp module, anyway, I can just import the\nsuperproject dsp as one remote branch into the dsp git repository and\ndo the merging there. There is no need to make dsp an actual\nsubmodule of the superproject for that as long as I am working with\ngit-svn.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"}]}