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 [off-list ref] 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 [off-list ref] wrote:

quoted

quoted

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