Re: git subtree oddity

Stephen Smith [off-list ref] 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.

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

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

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

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