{"thread":{"id":"7854","subject":"git submodule support feedback","startedAt":"2007-04-26T11:38:49Z","lastAt":"2007-04-26T21:49:55Z","messageCount":7,"participants":["Andy Parkins","Marco Costalba","David Lang","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40506","messageId":"200704261238.51234.andyparkins@gmail.com","threadId":"7854","inReplyTo":null,"subject":"git submodule support feedback","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T11:38:49Z","receivedAt":"2007-04-26T11:38:49Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI've started using submodule support in one of my projects.  I was previously \nusing my own poorman's submodule support where I kept the commit in a \nfile, .gitmodules.  Git's new submodule support is superior to this method \nand doesn't lose me any features over what I had so I thought I'd change.\n\nMy general comment is that it's great.  I've tried to trip it up a few times, \nbut it works exactly as one would expect.  I was surprised how little I had \nto understand in order to make it work, I didn't even need git update-index.  \ngit-add and git-rm work fine when the directory you're adding is a git \nrepository in itself.  Lovely.\n\nI'll report further as I come across any stumbling blocks; but here is one to \nget you going: (It's not a problem with git really, and the workaround is \nsimple, I'm reporting it for your information rather than to get it fixed).\n\nIn the master branch I deleted my .gitmodules file and did\n \n $ git add submodule\n $ git commit -m \"Chuck poorman's-submodule use gitman's-submodule\"\n\nThis took over the submodule management beautifully.  Now, I swapped to \nanother branch and tried to merge the master branch:\n\n $ git checkout somebranch\n $ git merge master\n fatal: Updating 'submodule' would lose untracked files in it\n Merge with strategy recursive failed.\n\nI appreciate why this has happened - submodule, from the point of view of \ngit - doesn't exist in that branch, but the directory always has, as that's \nwhere I've kept it as my pseudo-submodule.  The fix was to do\n\n $ mv submodule submodule.tmp\n $ git merge master\n $ rmdir submodule\n $ mv submodule.tmp submodule\n\nI bring this up only because anyone who's moving from non-submodule to \nsubmodule support might run into the same problem.\n\nIn short: great stuff - this is already more facility than I had, thanks \nchaps.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40507","messageId":"e5bfff550704260456r36bd7e0p8c4b18b1050ceb86@mail.gmail.com","threadId":"7854","inReplyTo":"200704261238.51234.andyparkins@gmail.com","subject":"Re: git submodule support feedback","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-04-26T11:56:52Z","receivedAt":"2007-04-26T11:56:52Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 4/26/07, Andy Parkins <andyparkins@gmail.com> wrote:\n> Hello,\n>\n>\n> I'll report further as I come across any stumbling blocks; but here is one to\n> get you going: (It's not a problem with git really, and the workaround is\n> simple, I'm reporting it for your information rather than to get it fixed).\n>\n\nHi Andy,\n\nbecause submodules are a new feature I would not be surprised if some\nsmall correction is needed in qgit code to correctly handle that.\n\n  In case you use qgit I would appreciate very much any bug report\nregarding this new submodules thing.\n\nI still didn't test submodules compatibility myself, but in case of a\nbug report against qgit probably I will be forced to do ;-)\n\nThanks\nMarco\n"},{"id":"40509","messageId":"200704261308.26451.andyparkins@gmail.com","threadId":"7854","inReplyTo":"e5bfff550704260456r36bd7e0p8c4b18b1050ceb86@mail.gmail.com","subject":"Re: git submodule support feedback","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T12:08:24Z","receivedAt":"2007-04-26T12:08:24Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 April 26, Marco Costalba wrote:\n\n>   In case you use qgit I would appreciate very much any bug report\n> regarding this new submodules thing.\n\nOf course; however, as of yet it's coping admirably.  I think that it's mainly \nbecause submodules are, for external-to-git purposes, displayed as patches to \na file.\n\nThat means that qgit is showing the initial addition of a submodule as the \naddition of a file (which nicely shows up green in the file list), and the \npatch itself as:\n\ndiff --git a/submodule b/submodule\nnew file mode 160000\nindex 0000000..f806cbe\n--- /dev/null\n+++ b/submodule\n@@ -0,0 +1 @@\n+Subproject commit f806cbe233f4568611be37213c266013b692db19\n\n> I still didn't test submodules compatibility myself, but in case of a\n> bug report against qgit probably I will be forced to do ;-)\n\nI'll certainly keep my eyes open.  As I say though: no worries yet.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40539","messageId":"Pine.LNX.4.63.0704261358170.9674@qynat.qvtvafvgr.pbz","threadId":"7854","inReplyTo":"200704262228.46864.andyparkins@gmail.com","subject":"Re: git submodule support feedback","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-04-26T20:59:19Z","receivedAt":"2007-04-26T20:59:19Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Thu, 26 Apr 2007, Andy Parkins wrote:\n\n> On Thursday 2007, April 26, Andy Parkins wrote:\n>\n>> I'll report further as I come across any stumbling blocks; but here\n>\n> The submodule support requires the latest version of git right?  That's\n> going to cause trouble for people running different versions of git\n> (I've already experienced it in my own limited way - I had to upgrade\n> all the copies of git I have on my various computers before fetching\n> and pushing would work).  If the repository contains a submodule\n> reference it effectively becomes inaccessible by a version of git\n> without submodule support.\n>\n> I think that we might be able to avoid that problem though - am I right\n> in thinking that the problem is that all the tools need teaching not to\n> follow the gitlink object because that hash doesn't exist in _this_\n> tree it is a reference to a commit in another tree.\n>\n> Wouldn't it be better if the gitlink reference pointed at an object in\n> this tree which in turn referred to the submodule commit?  That way the\n> old versions of git would still work with submodule objects in the\n> repository because they would just see submodules as pointing at a\n> blob.\n\nif you need to teach your version of git to accept this object that then points \nto the new tree don't you have to upgrade it to a version that does this? at \nthat pont you could just upgrade to a version that supports them the current \nway.\n\nDavid Lang\n"},{"id":"40538","messageId":"200704262228.46864.andyparkins@gmail.com","threadId":"7854","inReplyTo":"200704261238.51234.andyparkins@gmail.com","subject":"Re: git submodule support feedback","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T21:28:44Z","receivedAt":"2007-04-26T21:28:44Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007, April 26, Andy Parkins wrote:\n\n> I'll report further as I come across any stumbling blocks; but here\n\nThe submodule support requires the latest version of git right?  That's \ngoing to cause trouble for people running different versions of git \n(I've already experienced it in my own limited way - I had to upgrade \nall the copies of git I have on my various computers before fetching \nand pushing would work).  If the repository contains a submodule \nreference it effectively becomes inaccessible by a version of git \nwithout submodule support.\n\nI think that we might be able to avoid that problem though - am I right \nin thinking that the problem is that all the tools need teaching not to \nfollow the gitlink object because that hash doesn't exist in _this_ \ntree it is a reference to a commit in another tree.\n\nWouldn't it be better if the gitlink reference pointed at an object in \nthis tree which in turn referred to the submodule commit?  That way the \nold versions of git would still work with submodule objects in the \nrepository because they would just see submodules as pointing at a \nblob.\n\nHave I oversimplified it in my head?\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40540","messageId":"7vfy6mstsd.fsf@assigned-by-dhcp.cox.net","threadId":"7854","inReplyTo":"200704262228.46864.andyparkins@gmail.com","subject":"Re: git submodule support feedback","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-26T21:35:46Z","receivedAt":"2007-04-26T21:35:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Thursday 2007, April 26, Andy Parkins wrote:\n>\n>> I'll report further as I come across any stumbling blocks; but here\n>\n> The submodule support requires the latest version of git right?  That's \n> going to cause trouble for people running different versions of git \n> (I've already experienced it in my own limited way - I had to upgrade \n> all the copies of git I have on my various computers before fetching \n> and pushing would work).  If the repository contains a submodule \n> reference it effectively becomes inaccessible by a version of git \n> without submodule support.\n>\n> I think that we might be able to avoid that problem though - am I right \n> in thinking that the problem is that all the tools need teaching not to \n> follow the gitlink object because that hash doesn't exist in _this_ \n> tree it is a reference to a commit in another tree.\n>\n> Wouldn't it be better if the gitlink reference pointed at an object in \n> this tree which in turn referred to the submodule commit?  That way the \n> old versions of git would still work with submodule objects in the \n> repository because they would just see submodules as pointing at a \n> blob.\n>\n> Have I oversimplified it in my head?\n\nI think older tools do not expect to find anything but tree or\nblob in a tree object to begin with.  Now your experimental\nrepository has a commit, which they do not expect to see and I\nthink they will be unhappy.\n\nIf you replace the commit objects in your trees with a new type\nof object 'gitlink', your older tools will have exactly the same\nproblem, won't they?\n"},{"id":"40544","messageId":"200704262249.57238.andyparkins@gmail.com","threadId":"7854","inReplyTo":"7vfy6mstsd.fsf@assigned-by-dhcp.cox.net","subject":"Re: git submodule support feedback","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T21:49:55Z","receivedAt":"2007-04-26T21:49:55Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007, April 26, Junio C Hamano wrote:\n\n> I think older tools do not expect to find anything but tree or\n> blob in a tree object to begin with.  Now your experimental\n> repository has a commit, which they do not expect to see and I\n> think they will be unhappy.\n>\n> If you replace the commit objects in your trees with a new type\n> of object 'gitlink', your older tools will have exactly the same\n> problem, won't they?\n\nI'm not sure, what I imagined was at the moment we have\n\n160000 commit 0fbbf28b0eefb1546d02aabb43fa2de9b9f6d5f2  submodule\n\nThe hash here is a commit hash in another repository so obviously all \nthe git tools from older versions instantly bomb out saying they can't \nfind that object.\n\nIf, on the other hand we had\n\n160000 blob b1819880ec7ead7354c6d1c650ea5faf9c6d629b  submodule\n\n$ git-cat-file -p b1819880ec7ead7354c6d1c650ea5faf9c6d629b\n0fbbf28b0eefb1546d02aabb43fa2de9b9f6d5f2\n\nObviously the current gitlink stuff would need rewriting to use this \nextra layer of indirection, but all the old tools would just see this \nas a blob and simply treat it as a file containing that hash.\n\nI'm kind of hoping that older versions of git would fail gracefully on a \n160000 file type.  If that isn't the case, then this is no solution and \nthere'd be no point going to any effort.\n\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"}]}