Re: git subtree oddity
Jeremy Rosen 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
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 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 > 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
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 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
> > 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
Stephen Smith writes: > 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? We have been carrying a copy of it in contrib/ but I have to say that it is in a sorry state. After the original author stopped working on it, a new maintainer of the subtree project picked it up. Some vocal users wanted to have it as a part of the git-core tarball, with a promise that it will be supported and maintained, and that is how we ended up carrying a copy of it in contrib/. We see some discussions and patches sent to the list from time to time, but I haven't been getting anything definitive from the new subtree maintainer for whatever reason (if I understand correctly, it is not his primary job; perhaps he is busy with other things) and the part of that contrib/ tree hasn't seen much activities. Also I occasionally see end-user questions here but I have a feeling that many go unanswered by area experts. 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. -- 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 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 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
