git subtree oddity

git subtree oddity

[Thomas Taranowski]

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
docs            gr-howto-write-a-block  README
dtools          gr-noaa                 README.building-boost
gnuradio-core   gr-pager                README.hacking
gr-analog       gr-qtgui                README-win32-mingw-short.txt
gr-atsc         gr-shd                  upstream <---- the subtree directory
gr-audio        gr-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
docs            gr-filter               gr-wavelet
dtools          gr-howto-write-a-block  gr-wxgui
gnuradio-core   gr-noaa                 README
gr-analog       gr-pager                README.building-boost
gr-atsc         gr-qtgui                README.hacking
gr-audio        gr-shd                  README-win32-mingw-short.txt
gr-blocks       gr-trellis              volk

Re: git subtree oddity

[Stephen Smith]

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 <tom@baringforge.com> 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
> docs            gr-howto-write-a-block  README
> dtools          gr-noaa                 README.building-boost
> gnuradio-core   gr-pager                README.hacking
> gr-analog       gr-qtgui                README-win32-mingw-short.txt
> gr-atsc         gr-shd                  upstream <---- the subtree directory
> gr-audio        gr-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
> docs            gr-filter               gr-wavelet
> dtools          gr-howto-write-a-block  gr-wxgui
> gnuradio-core   gr-noaa                 README
> gr-analog       gr-pager                README.building-boost
> gr-atsc         gr-qtgui                README.hacking
> gr-audio        gr-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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git subtree oddity

[Junio C Hamano]

Stephen Smith <ishchis2@gmail.com> 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.

Re: git subtree oddity

[Jeremy Rosen]

> 
> 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

Re: git subtree oddity

[Thomas Taranowski]

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@openwide.fr> 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

Re: git subtree oddity

[Thomas Taranowski]

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@baringforge.com> 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@openwide.fr> 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

Re: git subtree oddity

[Junio C Hamano]

Jeremy Rosen <jeremy.rosen@openwide.fr> 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.