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 <tom@xxxxxxxxxxxxxxx> 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.rosen@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html