{"thread":{"id":"7926","subject":"svn:externals using git submodules","startedAt":"2007-05-01T10:21:14Z","lastAt":"2010-01-20T13:58:18Z","messageCount":14,"participants":["Andy Parkins","Chris Shoemaker","Shawn O. Pearce","Linus Torvalds","Junio C Hamano","Michel Jouvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40815","messageId":"200705011121.17172.andyparkins@gmail.com","threadId":"7926","inReplyTo":null,"subject":"svn:externals using git submodules","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-01T10:21:14Z","receivedAt":"2007-05-01T10:21:14Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI've done this by hand as a proof of concept I suspect it would need loads of \nwork in git-svn to do it properly. However, I thought I'd mention as part of \nmy \"success with submodules\" reports.\n\nffmpeg is managed with svn; I like to track its development with git-svn. \nWorks wonderfully except for one problem: they've made use of svn:externals \nfor one component, libswscale. Previously I just regularly updated the \nlibswscale subdirectory by checking out the latest copy (which is all that \nsubversion does) and committing it to my own branch off upstream.\n\nWith submodule support in git, it makes it possible to do a much better job. \nWhat I did was have two svn-remote sections in the config:\n\n[svn-remote \"ffmpeg\"]\n url = svn://svn.mplayerhq.hu/ffmpeg\n fetch = trunk:refs/remotes/ffmpeg-svn\n\n[svn-remote \"libswscale\"]\n url = svn://svn.mplayerhq.hu/mplayer\n fetch = trunk/libswscale:refs/remotes/libswscale-svn\n\nAfter running git-svn fetch; there are two independent branches in my \nrepository:\n\n -- * -- * -- * -- * -- * (ffmpeg-svn)\n ---- * ----- * ------- * (libswscale-svn) \n\nNow, we fork from ffmpeg-svn and libswscale-svn to make non-tracking branches \nthat can be committed to:\n\n $ git checkout -b master-ffm ffmpeg-svn\n $ git branch master-sws libswscale-svn\n\nNext, we create a shared clone of the repository as a subdirectory in that \nrepository.\n\n $ git clone -s . libswscale\n\nNow we want that clone to be even more strongly linked to the parent - to the \nextent that they share the same refs, etc:\n\n $ cd libswscale\n $ rm -rf .git/refs .git/logs .git/info description config\n $ ln -s ../../.git/refs .git/refs\n $ ln -s ../../.git/logs .git/logs\n $ ln -s ../../.git/info .git/info\n $ ln -s ../../.git/config .git/config\n $ ln -s ../../.git/description .git/description\n\nOnly HEAD and index are independent. Next we switch from the ffmpeg branch to \nthe libswscale branch in this subdirectory:\n\n $ git checkout master-sws\n\nNow, we make the subdirectory a submodule in the parent:\n\n $ cd ..\n $ git add libswscale\n $ git commit -m \"libswscale is now a submodule\"\n\nHow dangerous is this? I've made the repository it's own submodule and it \nshares the same refs, info and logs. LIVING ON THE EDGE MAN!\n\nYou have to run two git-svn commands to sync with upstream:\n\n $ git-svn fetch ffmpeg\n $ git-svn fetch libswscale\n\nThen of course you would merge\n\n $ git merge ffmpeg-svn\n $ cd libswscale; git merge libswscale-svn; cd ..\n $ git commit -m \"Sync with upstream\"\n\nPersonally I think that's pretty cool, this is significantly better than \nsvn:externals because the particular revision of libswscale in use is \nrecorded. Seriously - someone show me another VCS that can do that - I think \ngit has actual magic powers :-)\n\nI dare say that git-svn could do much better because it could reconstruct the \nsubmodule history based on the repository dates and create the link in the \ntracking branch rather than having to do it manually at the end as I've done \nhere. That would mean that the recorded submodule was right for all \nhistory - again, not the case for svn:externals, if you check out a previous \nversion the external remains current.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40822","messageId":"20070501150724.GA20797@pe.Belkin","threadId":"7926","inReplyTo":"200705011121.17172.andyparkins@gmail.com","subject":"Re: svn:externals using git submodules","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-05-01T15:07:24Z","receivedAt":"2007-05-01T15:07:24Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Tue, May 01, 2007 at 11:21:14AM +0100, Andy Parkins wrote:\n> Hello,\n> \n> I've done this by hand as a proof of concept I suspect it would need loads of \n> work in git-svn to do it properly. However, I thought I'd mention as part of \n> my \"success with submodules\" reports.\n\nThat's truly interesting, Andy. Thanks for the encouraging report.\nPlease do keep us informed of anything more you conclude about this\napproach. I'm sure some of the experts around here can respond with\nthe pros and cons of this technique.\n\nFor my part, I wonder if it can be simplified somehow; and I suspect\nit doesn't work well with svn:externals that specify a particular\nrevision.\n\n-chris\n\n> ffmpeg is managed with svn; I like to track its development with git-svn. \n> Works wonderfully except for one problem: they've made use of svn:externals \n> for one component, libswscale. Previously I just regularly updated the \n> libswscale subdirectory by checking out the latest copy (which is all that \n> subversion does) and committing it to my own branch off upstream.\n> \n> With submodule support in git, it makes it possible to do a much better job. \n> What I did was have two svn-remote sections in the config:\n> \n> [svn-remote \"ffmpeg\"]\n> url = svn://svn.mplayerhq.hu/ffmpeg\n> fetch = trunk:refs/remotes/ffmpeg-svn\n> \n> [svn-remote \"libswscale\"]\n> url = svn://svn.mplayerhq.hu/mplayer\n> fetch = trunk/libswscale:refs/remotes/libswscale-svn\n> \n> After running git-svn fetch; there are two independent branches in my \n> repository:\n> \n> -- * -- * -- * -- * -- * (ffmpeg-svn)\n> ---- * ----- * ------- * (libswscale-svn) \n> \n> Now, we fork from ffmpeg-svn and libswscale-svn to make non-tracking branches \n> that can be committed to:\n> \n> $ git checkout -b master-ffm ffmpeg-svn\n> $ git branch master-sws libswscale-svn\n> \n> Next, we create a shared clone of the repository as a subdirectory in that \n> repository.\n> \n> $ git clone -s . libswscale\n> \n> Now we want that clone to be even more strongly linked to the parent - to the \n> extent that they share the same refs, etc:\n> \n> $ cd libswscale\n> $ rm -rf .git/refs .git/logs .git/info description config\n> $ ln -s ../../.git/refs .git/refs\n> $ ln -s ../../.git/logs .git/logs\n> $ ln -s ../../.git/info .git/info\n> $ ln -s ../../.git/config .git/config\n> $ ln -s ../../.git/description .git/description\n> \n> Only HEAD and index are independent. Next we switch from the ffmpeg branch to \n> the libswscale branch in this subdirectory:\n> \n> $ git checkout master-sws\n> \n> Now, we make the subdirectory a submodule in the parent:\n> \n> $ cd ..\n> $ git add libswscale\n> $ git commit -m \"libswscale is now a submodule\"\n> \n> How dangerous is this? I've made the repository it's own submodule and it \n> shares the same refs, info and logs. LIVING ON THE EDGE MAN!\n> \n> You have to run two git-svn commands to sync with upstream:\n> \n> $ git-svn fetch ffmpeg\n> $ git-svn fetch libswscale\n> \n> Then of course you would merge\n> \n> $ git merge ffmpeg-svn\n> $ cd libswscale; git merge libswscale-svn; cd ..\n> $ git commit -m \"Sync with upstream\"\n> \n> Personally I think that's pretty cool, this is significantly better than \n> svn:externals because the particular revision of libswscale in use is \n> recorded. Seriously - someone show me another VCS that can do that - I think \n> git has actual magic powers :-)\n> \n> I dare say that git-svn could do much better because it could reconstruct the \n> submodule history based on the repository dates and create the link in the \n> tracking branch rather than having to do it manually at the end as I've done \n> here. That would mean that the recorded submodule was right for all \n> history - again, not the case for svn:externals, if you check out a previous \n> version the external remains current.\n> \n> \n> \n> Andy\n> -- \n> Dr Andy Parkins, M Eng (hons), MIET\n> andyparkins@gmail.com\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"40823","messageId":"20070501152228.GF5942@spearce.org","threadId":"7926","inReplyTo":"20070501150724.GA20797@pe.Belkin","subject":"Re: svn:externals using git submodules","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-01T15:22:28Z","receivedAt":"2007-05-01T15:22:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Chris Shoemaker wrote:\n> On Tue, May 01, 2007 at 11:21:14AM +0100, Andy Parkins wrote:\n> > Hello,\n> > \n> > I've done this by hand as a proof of concept I suspect it would need loads of \n> > work in git-svn to do it properly. However, I thought I'd mention as part of \n> > my \"success with submodules\" reports.\n> \n> For my part, I wonder if it can be simplified somehow; and I suspect\n> it doesn't work well with svn:externals that specify a particular\n> revision.\n\nActually that is an interesting point that Chris makes. Isn't the\nsvn:externals property revision controlled on the parent directory?\nSo each change to it is actually recorded in the revision history\nof the parent project. And if every svn:externals URL included the\nexact version of the other project to include, aren't svn:externals\nthen more-or-less like the subproject link support, except they\nalso include the URL?\n\n-- \nShawn.\n"},{"id":"40825","messageId":"20070501153626.GA21182@pe.Belkin","threadId":"7926","inReplyTo":"20070501152228.GF5942@spearce.org","subject":"Re: svn:externals using git submodules","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-05-01T15:36:26Z","receivedAt":"2007-05-01T15:36:26Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Tue, May 01, 2007 at 11:22:28AM -0400, Shawn O. Pearce wrote:\n> Chris Shoemaker wrote:\n> > On Tue, May 01, 2007 at 11:21:14AM +0100, Andy Parkins wrote:\n> > > Hello,\n> > > \n> > > I've done this by hand as a proof of concept I suspect it would need loads of \n> > > work in git-svn to do it properly. However, I thought I'd mention as part of \n> > > my \"success with submodules\" reports.\n> > \n> > For my part, I wonder if it can be simplified somehow; and I suspect\n> > it doesn't work well with svn:externals that specify a particular\n> > revision.\n> \n> Actually that is an interesting point that Chris makes. Isn't the\n> svn:externals property revision controlled on the parent directory?\n> So each change to it is actually recorded in the revision history\n> of the parent project. \n\nYes and yes.\n\n> And if every svn:externals URL included the\n> exact version of the other project to include, aren't svn:externals\n> then more-or-less like the subproject link support, except they\n> also include the URL?\n\nJust to clarify, my point was just that Andy's setup seems to assume\nthat the externals don't specify a revision. If they do, maybe\ngit-svn can map the externals into subprojects. Is this what\nyou're thinking?\n\n-chris\n\n> \n> -- \n> Shawn.\n"},{"id":"40826","messageId":"20070501154056.GH5942@spearce.org","threadId":"7926","inReplyTo":"20070501153626.GA21182@pe.Belkin","subject":"Re: svn:externals using git submodules","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-01T15:40:56Z","receivedAt":"2007-05-01T15:40:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Chris Shoemaker wrote:\n> On Tue, May 01, 2007 at 11:22:28AM -0400, Shawn O. Pearce wrote:\n> > And if every svn:externals URL included the\n> > exact version of the other project to include, aren't svn:externals\n> > then more-or-less like the subproject link support, except they\n> > also include the URL?\n> \n> Just to clarify, my point was just that Andy's setup seems to assume\n> that the externals don't specify a revision. If they do, maybe\n> git-svn can map the externals into subprojects. Is this what\n> you're thinking?\n\nYes. ;-)\n\n-- \nShawn.\n"},{"id":"40844","messageId":"200705011936.14345.andyparkins@gmail.com","threadId":"7926","inReplyTo":"20070501153626.GA21182@pe.Belkin","subject":"Re: svn:externals using git submodules","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-01T18:36:11Z","receivedAt":"2007-05-01T18:36:11Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007, May 01, Chris Shoemaker wrote:\n\n> > Actually that is an interesting point that Chris makes. Isn't the\n> > svn:externals property revision controlled on the parent directory?\n> > So each change to it is actually recorded in the revision history\n> > of the parent project.\n>\n> Yes and yes.\n\nYes and no. Think of svn:externals as a file in the parent repository; \nit contains\n\n directory-name URL\n\nNow, changes to that file _are_ tracked, in that if I changed the URL \nthat change would be recorded in the parent repository. However, \nnowhere is the revision of the external recorded. Subversion always \nfetches the latest revision at that URL.\n\n> > And if every svn:externals URL included the\n> > exact version of the other project to include, aren't svn:externals\n> > then more-or-less like the subproject link support, except they\n> > also include the URL?\n>\n> Just to clarify, my point was just that Andy's setup seems to assume\n> that the externals don't specify a revision. If they do, maybe\n\nThey don't. If they did, they'd be just as useful as git's submodules.\n\n> git-svn can map the externals into subprojects. Is this what\n> you're thinking?\n\nWell, I'm thinking that that information /can/ be reconstructed from the \nrevision date information - kind of - the problem is that there is no \nway to know when the parent updated the module. svn:externals really \nis just a quick way of doing\n $ cd submodule\n $ svn update\nThat's it. That's all you get. We could guess that when the parent \nmodule was at date YYYY-MM-DD, that the submodule would be at that same \ndate - but who knows?\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40845","messageId":"200705011939.17846.andyparkins@gmail.com","threadId":"7926","inReplyTo":"200705011936.14345.andyparkins@gmail.com","subject":"Re: svn:externals using git submodules","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-01T18:39:16Z","receivedAt":"2007-05-01T18:39:16Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007, May 01, Andy Parkins wrote:\n\n> Now, changes to that file _are_ tracked, in that if I changed the URL\n> that change would be recorded in the parent repository. However,\n> nowhere is the revision of the external recorded. Subversion always\n> fetches the latest revision at that URL.\n\nI meant to add as well that this is absolutely NOT the thing that you \nwant to be tracked. There are any number of times while using \nexternals that I reorganised a directory only to have to change the \nsvn:externals in the parent. That change is then tracked, so if you \ncheck out an earlier version not only do you not get a particular \nrevision you also don't get the right URL, so subverion doesn't even \nfetch the current version. Gah!\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40849","messageId":"20070501191703.GA25287@pe.Belkin","threadId":"7926","inReplyTo":"200705011936.14345.andyparkins@gmail.com","subject":"Re: svn:externals using git submodules","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-05-01T19:17:03Z","receivedAt":"2007-05-01T19:17:03Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Tue, May 01, 2007 at 07:36:11PM +0100, Andy Parkins wrote:\n> On Tuesday 2007, May 01, Chris Shoemaker wrote:\n> \n> > > Actually that is an interesting point that Chris makes. Isn't the\n> > > svn:externals property revision controlled on the parent directory?\n> > > So each change to it is actually recorded in the revision history\n> > > of the parent project.\n> >\n> > Yes and yes.\n> \n> Yes and no. Think of svn:externals as a file in the parent repository; \n> it contains\n> \n> directory-name URL\n> \n> Now, changes to that file _are_ tracked, in that if I changed the URL \n> that change would be recorded in the parent repository. However, \n> nowhere is the revision of the external recorded. Subversion always \n> fetches the latest revision at that URL.\n\nThat's only true when the revision is not specified in the external.\nThe repo you track may not do that, but it's not uncommon to do so.\nAnd, as I think you're pointing out, it's the only way to get any sort\nof reliable information about the relationship between the parent and\nthe external.\n\nI think it would probably be undesirable for git-svn to attempt to\nconvert \"floating\" externals into well-versioned submodules, since\nthey're not even well-versioned in the svn repo. However, handling\nthe \"locked-down\" externals is quite another thing.\n\n> \n> > > And if every svn:externals URL included the\n> > > exact version of the other project to include, aren't svn:externals\n> > > then more-or-less like the subproject link support, except they\n> > > also include the URL?\n> >\n> > Just to clarify, my point was just that Andy's setup seems to assume\n> > that the externals don't specify a revision. If they do, maybe\n> \n> They don't. If they did, they'd be just as useful as git's submodules.\n>\n> > git-svn can map the externals into subprojects. Is this what\n> > you're thinking?\n> \n> Well, I'm thinking that that information /can/ be reconstructed from the \n> revision date information - kind of - the problem is that there is no \n> way to know when the parent updated the module. svn:externals really \n> is just a quick way of doing\n> $ cd submodule\n> $ svn update\n> That's it. That's all you get. We could guess that when the parent \n> module was at date YYYY-MM-DD, that the submodule would be at that same \n> date - but who knows?\n\nsvn users who want the externals to meaningfully define the version\nrelationship between the parent and the project already have to use\nexternals that specify a revision.\n\n-chris\n"},{"id":"40850","messageId":"200705012048.04817.andyparkins@gmail.com","threadId":"7926","inReplyTo":"20070501191703.GA25287@pe.Belkin","subject":"Re: svn:externals using git submodules","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-01T19:48:01Z","receivedAt":"2007-05-01T19:48:01Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007, May 01, Chris Shoemaker wrote:\n\n> That's only true when the revision is not specified in the external.\n> The repo you track may not do that, but it's not uncommon to do so.\n\nIt's been a while since I used subversion, and even longer since I used \nexternals - is that a new feature? I used subversion since before \nversion 1.0, so I often missed new features when they arrived. \n\n> And, as I think you're pointing out, it's the only way to get any\n> sort of reliable information about the relationship between the\n> parent and the external.\n\nDoes subversion automatically update that fixed attachment when you \nupdate the submodule? I would have found that quite useful back then.\n\n> I think it would probably be undesirable for git-svn to attempt to\n> convert \"floating\" externals into well-versioned submodules, since\n> they're not even well-versioned in the svn repo. However, handling\n> the \"locked-down\" externals is quite another thing.\n\nAbsolutely. If the information is available, then git is certainly \ncapable of recording it. It sounds like subversion has a facility I \ndidn't know exist, so I've been bad mouthing it more than I should. Oh \nwell :-)\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40852","messageId":"20070501202356.GA25531@pe.Belkin","threadId":"7926","inReplyTo":"200705012048.04817.andyparkins@gmail.com","subject":"Re: svn:externals using git submodules","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-05-01T20:23:56Z","receivedAt":"2007-05-01T20:23:56Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Tue, May 01, 2007 at 08:48:01PM +0100, Andy Parkins wrote:\n> On Tuesday 2007, May 01, Chris Shoemaker wrote:\n> \n> > That's only true when the revision is not specified in the external.\n> > The repo you track may not do that, but it's not uncommon to do so.\n> \n> It's been a while since I used subversion, and even longer since I used \n> externals - is that a new feature? \n\nI don't know, but I would guess that it's no newer than externals in\ngeneral, as it's not a particularly special case.\n\n> I used subversion since before \n> version 1.0, so I often missed new features when they arrived. \n> \n> > And, as I think you're pointing out, it's the only way to get any\n> > sort of reliable information about the relationship between the\n> > parent and the external.\n> \n> Does subversion automatically update that fixed attachment when you \n> update the submodule? I would have found that quite useful back then.\n\nNo, you have to manage the revision in the svn:external property\nmanually.\n\n> > I think it would probably be undesirable for git-svn to attempt to\n> > convert \"floating\" externals into well-versioned submodules, since\n> > they're not even well-versioned in the svn repo. However, handling\n> > the \"locked-down\" externals is quite another thing.\n> \n> Absolutely. If the information is available, then git is certainly \n> capable of recording it. It sounds like subversion has a facility I \n> didn't know exist, so I've been bad mouthing it more than I should. Oh \n> well :-)\n> \n\nMaking git-svn handle svn:externals with specified revisions would be\n_quite_ useful. There's a special-case of this that I use personally:\nsvn:externals that point to other paths (and other revisions) of the\nparent repo.\n\nI'm curious if people think that teaching git-svn to handle this\nspecial case is more or less difficult than handling the general case.\n\n-chris\n"},{"id":"40861","messageId":"alpine.LFD.0.98.0705011512300.3808@woody.linux-foundation.org","threadId":"7926","inReplyTo":"20070501202356.GA25531@pe.Belkin","subject":"Re: svn:externals using git submodules","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-01T22:19:10Z","receivedAt":"2007-05-01T22:19:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 1 May 2007, Chris Shoemaker wrote:\n> \n> Making git-svn handle svn:externals with specified revisions would be\n> _quite_ useful. There's a special-case of this that I use personally:\n> svn:externals that point to other paths (and other revisions) of the\n> parent repo.\n\nSide note: even _without_ a specified revision, I think it's quite sane to \nhave the rule that a submodule hash of all zeroes is \"unversioned\".\n\nSuch a submodule is still _useful_: while the tree itself contains no \ninformation (and it SHOULD NOT do so, since the actual location of the \nexternal module may not be globally stable or visible!), it would \nbasically act like subversion externals together with the \".gitmodules\" \nfile that contains that information.\n\nSo while the git submodule thing was designed to specify specific \nrevisions, there's nothing that really technically _requires_ it. The \nexact SHA1 details in the submodule link are going to be up to the \nhigher-level user anyway.\n\n(Of course, if you actually have a \"all zeroes\" gitlink entry, and then \nhave a checked-out git tree at that entry, \"git status\" and \"git diff\" \nwould show it as needing update. I think that's _correct_, but if we want \nto shut it up for the special case of all-zero SHA1, we trivially could).\n\nBut while I'm encouraged that the whole gitlink thing seems to be working \nfor Andy, and some others are playing with it too, I'm also a bit \ndiscouraged by the fact that there hasn't been any noise or work on the \nporcelain side. I was obviously optimistic and hoping we'd see support in \ncheckout/diff, but I haven't heard anybody talk about actually \nimplementing .gitmodules and the porcelain support that uses them..\n\n\t\t\tLinus\n"},{"id":"40865","messageId":"7vzm4o41bz.fsf@assigned-by-dhcp.cox.net","threadId":"7926","inReplyTo":"alpine.LFD.0.98.0705011512300.3808@woody.linux-foundation.org","subject":"Re: svn:externals using git submodules","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-01T22:37:52Z","receivedAt":"2007-05-01T22:37:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 1 May 2007, Chris Shoemaker wrote:\n>> \n>> Making git-svn handle svn:externals with specified revisions would be\n>> _quite_ useful. There's a special-case of this that I use personally:\n>> svn:externals that point to other paths (and other revisions) of the\n>> parent repo.\n>\n> Side note: even _without_ a specified revision, I think it's quite sane to \n> have the rule that a submodule hash of all zeroes is \"unversioned\".\n\nYup.\n\n> But while I'm encouraged that the whole gitlink thing seems to be working \n> for Andy, and some others are playing with it too, I'm also a bit \n> discouraged by the fact that there hasn't been any noise or work on the \n> porcelain side. I was obviously optimistic and hoping we'd see support in \n> checkout/diff, but I haven't heard anybody talk about actually \n> implementing .gitmodules and the porcelain support that uses them..\n\nThe thing is, almost all the core git people happen to be busy\nat the same time at this moment. Johannes has just moved, Shawn\nand I are deep in day-jobs to the neck, ...\n\nDon't worry, it eventually will come. \n"},{"id":"40868","messageId":"20070501231628.GJ5942@spearce.org","threadId":"7926","inReplyTo":"7vzm4o41bz.fsf@assigned-by-dhcp.cox.net","subject":"Re: svn:externals using git submodules","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-01T23:16:28Z","receivedAt":"2007-05-01T23:16:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n> > But while I'm encouraged that the whole gitlink thing seems to be working \n> > for Andy, and some others are playing with it too, I'm also a bit \n> > discouraged by the fact that there hasn't been any noise or work on the \n> > porcelain side. I was obviously optimistic and hoping we'd see support in \n> > checkout/diff, but I haven't heard anybody talk about actually \n> > implementing .gitmodules and the porcelain support that uses them..\n> \n> The thing is, almost all the core git people happen to be busy\n> at the same time at this moment. Johannes has just moved, Shawn\n> and I are deep in day-jobs to the neck, ...\n\nHeh, very true. My short-term focus (this week) is git-gui,\nthen pack v4, and probably while working on pack v4 start at least\nplaying with Linus' gitlink thing and prototyping porcleain over it.\nThe gitlink work interests me, and I want to spend time on it,\nbut as Junio said, I'm overbooked...\n\n-- \nShawn.\n"},{"id":"132194","messageId":"loom.20100120T145348-193@post.gmane.org","threadId":"7926","inReplyTo":"200705011121.17172.andyparkins@gmail.com","subject":"Re: svn:externals using git submodules","fromName":"Michel Jouvin","fromEmail":"jouvin@lal.in2p3.fr","sentAt":"2010-01-20T13:58:18Z","receivedAt":"2010-01-20T13:58:18Z","isPatch":false,"sender":{"key":"jouvin@lal.in2p3.fr","avatar":null},"body":"Andy Parkins gmail.com> writes:\n\n> \n> Hello,\n> \n> I've done this by hand as a proof of concept I suspect it would need loads of \n> work in git-svn to do it properly. However, I thought I'd mention as part of \n> my \"success with submodules\" reports.\n> \n> ... \n> Now we want that clone to be even more strongly linked to the parent - to the \n> extent that they share the same refs, etc:\n> \n> $ cd libswscale\n> $ rm -rf .git/refs .git/logs .git/info description config\n> $ ln -s ../../.git/refs .git/refs\n> $ ln -s ../../.git/logs .git/logs\n> $ ln -s ../../.git/info .git/info\n> $ ln -s ../../.git/config .git/config\n> $ ln -s ../../.git/description .git/description\n> \n> ...\n> Andy\n\nI don't know if it's a good idea to follow-up on such an old entry... but I \nused your trick, Andy, and it works pretty well. With one exception: I am using \nGit on Windows and there is no symlinks on this OS. That means that you need to \nbasically \"recreate\" the symlinks everytime you want to update the submodules. \nNot very handy but acceptable as they are not updated very often.\n\nI have to check the list if there has been some new ways to achieve this. But \nI'm clearly in the case of svn:externals not tighten to a particular revision, \nwhich seems the difficult case for Git.\n\nCheers,\n\nMichel\n"}]}