Re: git subtree oddity
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? SPS Sent from my iPhone On Mar 27, 2013, at 8:12 PM, Thomas Taranowski t...@baringforge.com wrote: I'd like to have the following configuration: /myproject.git |__/upstream_dependency -- Points to a remote library git repo |__/project_source -- local project source I issue the following commands to pull in the upstream dependency as a subtree of the myproject.git repo: git remote add upstream git://gnuradio.org/gnuradio git fetch upstream git checkout master git subtree add -P upstream upstream/master Now, my expectation is that I would have the following: /myproject.git |__/upstream_dependency -- Points to a remote library git repo | all the upstream files are present here, as expected |__/project_source this is still intact, as expected |__ all the upstream files are present here. wtf? My question is, why does subtree add pull in all the subtree files into the root of the repo, and not just into the specified subtree prefix? # # Here's an excerpt of what I see: # $:~/scratch/myproject.git$ ls AUTHORS gr-comedi gr-utils cmake gr-digital gr-video-sdl CMakeLists.txt gr-fcd gr-vocoder config.h.in gr-fft gr-wavelet COPYING gr-filter gr-wxgui docsgr-howto-write-a-block README dtools gr-noaa README.building-boost gnuradio-core gr-pagerREADME.hacking gr-analog gr-qtguiREADME-win32-mingw-short.txt gr-atsc gr-shd upstream the subtree directory gr-audiogr-trellis volk gr-blocks gruel grc gr-uh # # Also, those same files are in the upstream subtree directory as well (as expected) # $:~/scratch/myproject.git$ ls upstream AUTHORS grc gruel cmake gr-comedi gr-uhd CMakeLists.txt gr-digital gr-utils config.h.in gr-fcd gr-video-sdl COPYING gr-fft gr-vocoder docsgr-filter gr-wavelet dtools gr-howto-write-a-block gr-wxgui gnuradio-core gr-noaa README gr-analog gr-pagerREADME.building-boost gr-atsc gr-qtguiREADME.hacking gr-audiogr-shd README-win32-mingw-short.txt gr-blocks gr-trellis volk -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git subtree oddity
I am starting to regret that I caved in and started carrying a copy of it in contrib/. It probably is a good idea to drop it from my tree and let it mature and eventually flourish outside. that's a shame... it solves a real problem, is simple to use, and really powerfull. 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. 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 ? currently the problem of a git repo in a git repo is very complicated to deal with in a clean way... Regards Jérémy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git subtree oddity
I agree that subtree solves some specific use cases I would like to support. In particular, I was hoping to use the subtree command in lieu of using the subtree merge strategy to manage and overlay changes to upstream projects, as well as other local components. At any rate, it looks like the problem I'm having is not entirely related to the subtree command, but happens when I checkout a remote into a branch ( which subtree is presumably doing in the background). It's the same setup as before. Here is the sequence of commands I'm running. git init git remote add upstream git://gnuradio.org/gnuradio fetch upstream git checkout -b upstream_tracking upstream/master Now, at this point, I expect the upstream branch to contain the contents of the gnuradio project. I also expect that my local mater branch has only the contents of my local sources, and NOT the contents of the gnuradio. However, if I 'git checkout master', I see the contents of the gnuradio project. Why, when I checkout a branch tracking upstream/master, do the changes also appear on my master branch, and not just in the remote tracking branch? As a reference, this is close to what I'm trying to accomplish. His screenshot titled 'Directory Listing in Master' shows what I expect. http://typecastexception.com/post/2013/03/16/Managing-Nested-Libraries-Using-the-GIT-Subtree-Merge-Workflow.aspx Thanks -Tom Taranowski On Thu, Mar 28, 2013 at 9:34 AM, Jeremy Rosen jeremy.ro...@openwide.fr wrote: I am starting to regret that I caved in and started carrying a copy of it in contrib/. It probably is a good idea to drop it from my tree and let it mature and eventually flourish outside. that's a shame... it solves a real problem, is simple to use, and really powerfull. 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. 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 ? currently the problem of a git repo in a git repo is very complicated to deal with in a clean way... Regards Jérémy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git subtree oddity
Oh, this is odd. I can get the behavior I want by adding the '-f' flag to the remote add. So: git remote add -f upstream git://gnuradio.org/gnuradio According to the remote add help, the -f is only doing a fetch, which I was doing as a manual step after the remote add. Another interesting artifact is that I know see the warning: no common commits log, which I wasn't seeing in my prior process. So, my problem is 'fixed' now, but it seems like this is a bug, particularly since most of the subtree merge tuturoials I've seen online do the manual fetch step. Is there any additional information that would be useful for folks to see? -Tom On Thu, Mar 28, 2013 at 12:29 PM, Thomas Taranowski t...@baringforge.com wrote: I agree that subtree solves some specific use cases I would like to support. In particular, I was hoping to use the subtree command in lieu of using the subtree merge strategy to manage and overlay changes to upstream projects, as well as other local components. At any rate, it looks like the problem I'm having is not entirely related to the subtree command, but happens when I checkout a remote into a branch ( which subtree is presumably doing in the background). It's the same setup as before. Here is the sequence of commands I'm running. git init git remote add upstream git://gnuradio.org/gnuradio fetch upstream git checkout -b upstream_tracking upstream/master Now, at this point, I expect the upstream branch to contain the contents of the gnuradio project. I also expect that my local mater branch has only the contents of my local sources, and NOT the contents of the gnuradio. However, if I 'git checkout master', I see the contents of the gnuradio project. Why, when I checkout a branch tracking upstream/master, do the changes also appear on my master branch, and not just in the remote tracking branch? As a reference, this is close to what I'm trying to accomplish. His screenshot titled 'Directory Listing in Master' shows what I expect. http://typecastexception.com/post/2013/03/16/Managing-Nested-Libraries-Using-the-GIT-Subtree-Merge-Workflow.aspx Thanks -Tom Taranowski On Thu, Mar 28, 2013 at 9:34 AM, Jeremy Rosen jeremy.ro...@openwide.fr wrote: I am starting to regret that I caved in and started carrying a copy of it in contrib/. It probably is a good idea to drop it from my tree and let it mature and eventually flourish outside. that's a shame... it solves a real problem, is simple to use, and really powerfull. 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. 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 ? currently the problem of a git repo in a git repo is very complicated to deal with in a clean way... Regards Jérémy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git subtree oddity
Jeremy Rosen jeremy.ro...@openwide.fr writes: I am starting to regret that I caved in and started carrying a copy of it in contrib/. It probably is a good idea to drop it from my tree and let it mature and eventually flourish outside. that's a shame... it solves a real problem, is simple to use, and really powerfull. I've never said the program does not solve a real problem, it is hard to use, nor it is useless. It just is not well maintained. I knew (and I said), from the very beginning when people started making noises about adding it to my tree, that I will not be a good maintainer for it. I am not its user, I do not know what its users expect out of the program, and I cannot read from its history what the developers were thinking when they designed its features and implemented its internals. I started carrying it in contrib/ only to give it wider exposure, but under the condition that somebody else would be the real maintainer for it. I'd say we should wait for at least a few days to see what David says. Perhaps he is too busy with other things. Perhaps he needs co-maintainers who are also interested in the program to help him. Leaving it in my tree without real maintenance is not an ideal state. I do not know why you think it is a shame. I honestly think it will do better outside my tree. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
