{"thread":{"id":"33314","subject":"git subtree oddity","startedAt":"2013-03-28T03:12:56Z","lastAt":"2013-03-29T05:47:18Z","messageCount":7,"participants":["Thomas Taranowski","Stephen Smith","Junio C Hamano","Jeremy Rosen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"212488","messageId":"CAH0ocawbOX8C7_EaNFc2PiFT8cnpSJyPD+-8RLDL1S0SX-jQvw@mail.gmail.com","threadId":"33314","inReplyTo":null,"subject":"git subtree oddity","fromName":"Thomas Taranowski","fromEmail":"tom@baringforge.com","sentAt":"2013-03-28T03:12:56Z","receivedAt":"2013-03-28T03:12:56Z","isPatch":false,"sender":{"key":"tom@baringforge.com","avatar":null},"body":"I'd like to have the following configuration:\n\n/myproject.git\n|__/upstream_dependency -- Points to a remote library git repo\n|__/project_source -- local project source\n\n\nI issue the following commands to pull in the upstream dependency as a\nsubtree of the myproject.git repo:\n\ngit remote add upstream git://gnuradio.org/gnuradio\ngit fetch upstream\ngit checkout master\ngit subtree add -P upstream upstream/master\n\nNow, my expectation is that I would have the following:\n\n/myproject.git\n|__/upstream_dependency -- Points to a remote library git repo\n|____< all the upstream files are present here, as expected >\n|__/project_source < this is still intact, as expected >\n|__< all the upstream files are present here. wtf?>\n\nMy question is, why does \"subtree add\" pull in all the subtree files\ninto the root of the repo, and not just into the specified subtree\nprefix?\n\n#\n# Here's an excerpt of what I see:\n#\n$:~/scratch/myproject.git$ ls\nAUTHORS gr-comedi gr-utils\ncmake gr-digital gr-video-sdl\nCMakeLists.txt gr-fcd gr-vocoder\nconfig.h.in gr-fft gr-wavelet\nCOPYING gr-filter gr-wxgui\ndocs gr-howto-write-a-block README\ndtools gr-noaa README.building-boost\ngnuradio-core gr-pager README.hacking\ngr-analog gr-qtgui README-win32-mingw-short.txt\ngr-atsc gr-shd upstream <---- the subtree directory\ngr-audio gr-trellis volk\ngr-blocks gruel\ngrc gr-uh\n\n#\n# Also, those same files are in the upstream subtree directory as well\n(as expected)\n#\n$:~/scratch/myproject.git$ ls upstream\nAUTHORS grc gruel\ncmake gr-comedi gr-uhd\nCMakeLists.txt gr-digital gr-utils\nconfig.h.in gr-fcd gr-video-sdl\nCOPYING gr-fft gr-vocoder\ndocs gr-filter gr-wavelet\ndtools gr-howto-write-a-block gr-wxgui\ngnuradio-core gr-noaa README\ngr-analog gr-pager README.building-boost\ngr-atsc gr-qtgui README.hacking\ngr-audio gr-shd README-win32-mingw-short.txt\ngr-blocks gr-trellis volk\n"},{"id":"212514","messageId":"A344B55C-0796-4739-8F44-F7BA26EA4B32@gmail.com","threadId":"33314","inReplyTo":"CAH0ocawbOX8C7_EaNFc2PiFT8cnpSJyPD+-8RLDL1S0SX-jQvw@mail.gmail.com","subject":"Re: git subtree oddity","fromName":"Stephen Smith","fromEmail":"ishchis2@gmail.com","sentAt":"2013-03-28T13:34:01Z","receivedAt":"2013-03-28T13:34:01Z","isPatch":false,"sender":{"key":"ishchis2@gmail.com","avatar":null},"body":"I built v1.8.2 last evening and found that the subtree command isn't supported. What version of git are you using? And where did you get it?\n\nSPS\nSent from my iPhone\n\nOn Mar 27, 2013, at 8:12 PM, Thomas Taranowski wrote:\n\n> I'd like to have the following configuration:\n> \n> /myproject.git\n> |__/upstream_dependency -- Points to a remote library git repo\n> |__/project_source -- local project source\n> \n> \n> I issue the following commands to pull in the upstream dependency as a\n> subtree of the myproject.git repo:\n> \n> git remote add upstream git://gnuradio.org/gnuradio\n> git fetch upstream\n> git checkout master\n> git subtree add -P upstream upstream/master\n> \n> Now, my expectation is that I would have the following:\n> \n> /myproject.git\n> |__/upstream_dependency -- Points to a remote library git repo\n> |____< all the upstream files are present here, as expected >\n> |__/project_source < this is still intact, as expected >\n> |__< all the upstream files are present here. wtf?>\n> \n> My question is, why does \"subtree add\" pull in all the subtree files\n> into the root of the repo, and not just into the specified subtree\n> prefix?\n> \n> #\n> # Here's an excerpt of what I see:\n> #\n> $:~/scratch/myproject.git$ ls\n> AUTHORS gr-comedi gr-utils\n> cmake gr-digital gr-video-sdl\n> CMakeLists.txt gr-fcd gr-vocoder\n> config.h.in gr-fft gr-wavelet\n> COPYING gr-filter gr-wxgui\n> docs gr-howto-write-a-block README\n> dtools gr-noaa README.building-boost\n> gnuradio-core gr-pager README.hacking\n> gr-analog gr-qtgui README-win32-mingw-short.txt\n> gr-atsc gr-shd upstream <---- the subtree directory\n> gr-audio gr-trellis volk\n> gr-blocks gruel\n> grc gr-uh\n> \n> #\n> # Also, those same files are in the upstream subtree directory as well\n> (as expected)\n> #\n> $:~/scratch/myproject.git$ ls upstream\n> AUTHORS grc gruel\n> cmake gr-comedi gr-uhd\n> CMakeLists.txt gr-digital gr-utils\n> config.h.in gr-fcd gr-video-sdl\n> COPYING gr-fft gr-vocoder\n> docs gr-filter gr-wavelet\n> dtools gr-howto-write-a-block gr-wxgui\n> gnuradio-core gr-noaa README\n> gr-analog gr-pager README.building-boost\n> gr-atsc gr-qtgui README.hacking\n> gr-audio gr-shd README-win32-mingw-short.txt\n> gr-blocks gr-trellis volk\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":"212538","messageId":"7v38vfwlxv.fsf@alter.siamese.dyndns.org","threadId":"33314","inReplyTo":"A344B55C-0796-4739-8F44-F7BA26EA4B32@gmail.com","subject":"Re: git subtree oddity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-28T16:03:56Z","receivedAt":"2013-03-28T16:03:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Smith writes:\n\n> I built v1.8.2 last evening and found that the subtree command\n> isn't supported. What version of git are you using? And where did\n> you get it?\n\nWe have been carrying a copy of it in contrib/ but I have to say\nthat it is in a sorry state.\n\nAfter the original author stopped working on it, a new maintainer of\nthe subtree project picked it up. Some vocal users wanted to have\nit as a part of the git-core tarball, with a promise that it will be\nsupported and maintained, and that is how we ended up carrying a\ncopy of it in contrib/. We see some discussions and patches sent to\nthe list from time to time, but I haven't been getting anything\ndefinitive from the new subtree maintainer for whatever reason (if I\nunderstand correctly, it is not his primary job; perhaps he is busy\nwith other things) and the part of that contrib/ tree hasn't seen\nmuch activities. Also I occasionally see end-user questions here\nbut I have a feeling that many go unanswered by area experts.\n\nI am starting to regret that I caved in and started carrying a copy\nof it in contrib/. It probably is a good idea to drop it from my\ntree and let it mature and eventually flourish outside.\n"},{"id":"212544","messageId":"1827202810.1012362.1364488493363.JavaMail.root@openwide.fr","threadId":"33314","inReplyTo":"7v38vfwlxv.fsf@alter.siamese.dyndns.org","subject":"Re: git subtree oddity","fromName":"Jeremy Rosen","fromEmail":"jeremy.rosen@openwide.fr","sentAt":"2013-03-28T16:34:53Z","receivedAt":"2013-03-28T16:34:53Z","isPatch":false,"sender":{"key":"jeremy.rosen@openwide.fr","avatar":null},"body":"> \n> I am starting to regret that I caved in and started carrying a copy\n> of it in contrib/. It probably is a good idea to drop it from my\n> tree and let it mature and eventually flourish outside.\n> \n\nthat's a shame... it solves a real problem, is simple to use, and really powerfull. \n\nbut unfortunately, I have sent a patch that solves a serious bug... which had already been reported and patched but had received no answer, and nobody replied to it.\n\nIs there anything that can be done to get this rolling, or a way to have the use-case it covers better handle by git-submodule ?\n\n\ncurrently the problem of a git repo in a git repo is very complicated to deal with in a clean way...\n\n\nRegards\n\nJérémy\n"},{"id":"212571","messageId":"CAH0ocazrojrJPdDDmLyL3RQaxxGjPnmhxq+FzSE0P9Y3Y05C1Q@mail.gmail.com","threadId":"33314","inReplyTo":"1827202810.1012362.1364488493363.JavaMail.root@openwide.fr","subject":"Re: git subtree oddity","fromName":"Thomas Taranowski","fromEmail":"tom@baringforge.com","sentAt":"2013-03-28T19:29:17Z","receivedAt":"2013-03-28T19:29:17Z","isPatch":false,"sender":{"key":"tom@baringforge.com","avatar":null},"body":"I agree that subtree solves some specific use cases I would like to\nsupport. In particular, I was hoping to use the subtree command in\nlieu of using the subtree merge strategy to manage and overlay changes\nto upstream projects, as well as other local components.\n\nAt any rate, it looks like the problem I'm having is not entirely\nrelated to the subtree command, but happens when I checkout a remote\ninto a branch ( which subtree is presumably doing in the background).\n\nIt's the same setup as before. Here is the sequence of commands I'm running.\n\ngit init\ngit remote add upstream git://gnuradio.org/gnuradio\nfetch upstream\ngit checkout -b upstream_tracking upstream/master\n\nNow, at this point, I expect the upstream branch to contain the\ncontents of the gnuradio project. I also expect that my local mater\nbranch has only the contents of my local sources, and NOT the contents\nof the gnuradio. However, if I 'git checkout master', I see the\ncontents of the gnuradio project. Why, when I checkout a branch\ntracking upstream/master, do the changes also appear on my master\nbranch, and not just in the remote tracking branch?\n\nAs a reference, this is close to what I'm trying to accomplish. His\nscreenshot titled 'Directory Listing in Master' shows what I expect.\nhttp://typecastexception.com/post/2013/03/16/Managing-Nested-Libraries-Using-the-GIT-Subtree-Merge-Workflow.aspx\n\nThanks\n-Tom Taranowski\n\nOn Thu, Mar 28, 2013 at 9:34 AM, Jeremy Rosen wrote:\n>>\n>> I am starting to regret that I caved in and started carrying a copy\n>> of it in contrib/. It probably is a good idea to drop it from my\n>> tree and let it mature and eventually flourish outside.\n>>\n>\n> that's a shame... it solves a real problem, is simple to use, and really powerfull.\n>\n> but unfortunately, I have sent a patch that solves a serious bug... which had already been reported and patched but had received no answer, and nobody replied to it.\n>\n> Is there anything that can be done to get this rolling, or a way to have the use-case it covers better handle by git-submodule ?\n>\n>\n> currently the problem of a git repo in a git repo is very complicated to deal with in a clean way...\n>\n>\n> Regards\n>\n> Jérémy\n"},{"id":"212573","messageId":"CAH0ocayVmTOFjTkYBRuA6RULafD1zY6hq1PWHWKONL9o24SFUA@mail.gmail.com","threadId":"33314","inReplyTo":"CAH0ocazrojrJPdDDmLyL3RQaxxGjPnmhxq+FzSE0P9Y3Y05C1Q@mail.gmail.com","subject":"Re: git subtree oddity","fromName":"Thomas Taranowski","fromEmail":"tom@baringforge.com","sentAt":"2013-03-28T19:44:11Z","receivedAt":"2013-03-28T19:44:11Z","isPatch":false,"sender":{"key":"tom@baringforge.com","avatar":null},"body":"Oh, this is odd. I can get the behavior I want by adding the '-f'\nflag to the remote add.\n\nSo: git remote add -f upstream git://gnuradio.org/gnuradio\n\nAccording to the remote add help, the -f is only doing a fetch, which\nI was doing as a manual step after the remote add.\n\nAnother interesting artifact is that I know see the \"warning: no\ncommon commits\" log, which I wasn't seeing in my prior process.\n\nSo, my problem is 'fixed' now, but it seems like this is a bug,\nparticularly since most of the subtree merge tuturoials I've seen\nonline do the manual fetch step. Is there any additional information\nthat would be useful for folks to see?\n\n-Tom\n\nOn Thu, Mar 28, 2013 at 12:29 PM, Thomas Taranowski wrote:\n> I agree that subtree solves some specific use cases I would like to\n> support. In particular, I was hoping to use the subtree command in\n> lieu of using the subtree merge strategy to manage and overlay changes\n> to upstream projects, as well as other local components.\n>\n> At any rate, it looks like the problem I'm having is not entirely\n> related to the subtree command, but happens when I checkout a remote\n> into a branch ( which subtree is presumably doing in the background).\n>\n> It's the same setup as before. Here is the sequence of commands I'm running.\n>\n> git init\n> git remote add upstream git://gnuradio.org/gnuradio\n> fetch upstream\n> git checkout -b upstream_tracking upstream/master\n>\n> Now, at this point, I expect the upstream branch to contain the\n> contents of the gnuradio project. I also expect that my local mater\n> branch has only the contents of my local sources, and NOT the contents\n> of the gnuradio. However, if I 'git checkout master', I see the\n> contents of the gnuradio project. Why, when I checkout a branch\n> tracking upstream/master, do the changes also appear on my master\n> branch, and not just in the remote tracking branch?\n>\n> As a reference, this is close to what I'm trying to accomplish. His\n> screenshot titled 'Directory Listing in Master' shows what I expect.\n> http://typecastexception.com/post/2013/03/16/Managing-Nested-Libraries-Using-the-GIT-Subtree-Merge-Workflow.aspx\n>\n> Thanks\n> -Tom Taranowski\n>\n> On Thu, Mar 28, 2013 at 9:34 AM, Jeremy Rosen wrote:\n>>>\n>>> I am starting to regret that I caved in and started carrying a copy\n>>> of it in contrib/. It probably is a good idea to drop it from my\n>>> tree and let it mature and eventually flourish outside.\n>>>\n>>\n>> that's a shame... it solves a real problem, is simple to use, and really powerfull.\n>>\n>> but unfortunately, I have sent a patch that solves a serious bug... which had already been reported and patched but had received no answer, and nobody replied to it.\n>>\n>> Is there anything that can be done to get this rolling, or a way to have the use-case it covers better handle by git-submodule ?\n>>\n>>\n>> currently the problem of a git repo in a git repo is very complicated to deal with in a clean way...\n>>\n>>\n>> Regards\n>>\n>> Jérémy\n"},{"id":"212604","messageId":"7v38verc49.fsf@alter.siamese.dyndns.org","threadId":"33314","inReplyTo":"1827202810.1012362.1364488493363.JavaMail.root@openwide.fr","subject":"Re: git subtree oddity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-29T05:47:18Z","receivedAt":"2013-03-29T05:47:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremy Rosen writes:\n\n>> I am starting to regret that I caved in and started carrying a\n>> copy of it in contrib/. It probably is a good idea to drop it\n>> from my tree and let it mature and eventually flourish outside.\n>\n> that's a shame... it solves a real problem, is simple to use, and\n> really powerfull.\n\nI've never said the program does not solve a real problem, it is\nhard to use, nor it is useless. It just is not well maintained.\n\nI knew (and I said), from the very beginning when people started\nmaking noises about adding it to my tree, that I will not be a good\nmaintainer for it. I am not its user, I do not know what its users\nexpect out of the program, and I cannot read from its history what\nthe developers were thinking when they designed its features and\nimplemented its internals.\n\nI started carrying it in contrib/ only to give it wider exposure,\nbut under the condition that somebody else would be the real\nmaintainer for it.\n\nI'd say we should wait for at least a few days to see what David\nsays. Perhaps he is too busy with other things. Perhaps he needs\nco-maintainers who are also interested in the program to help him.\n\nLeaving it in my tree without real maintenance is not an ideal\nstate. I do not know why you think it is a shame. I honestly think\nit will do better outside my tree.\n"}]}