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?
On Thu, Mar 28, 2013 at 12:29 PM, Thomas Taranowski <t...@baringforge.com>
> 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.
> -Tom Taranowski
> On Thu, Mar 28, 2013 at 9:34 AM, Jeremy Rosen <jeremy.ro...@openwide.fr>
>>> 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
>> 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...
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