* git subtree oddity
@ 2013-03-28 3:12 Thomas Taranowski
2013-03-28 13:34 ` Stephen Smith
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Taranowski @ 2013-03-28 3:12 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git subtree oddity
2013-03-28 3:12 git subtree oddity Thomas Taranowski
@ 2013-03-28 13:34 ` Stephen Smith
2013-03-28 16:03 ` Junio C Hamano
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Smith @ 2013-03-28 13:34 UTC (permalink / raw)
To: Thomas Taranowski; +Cc: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git subtree oddity
2013-03-28 13:34 ` Stephen Smith
@ 2013-03-28 16:03 ` Junio C Hamano
2013-03-28 16:34 ` Jeremy Rosen
0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2013-03-28 16:03 UTC (permalink / raw)
To: Stephen Smith; +Cc: Thomas Taranowski, git, David A. Greene
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git subtree oddity
2013-03-28 16:03 ` Junio C Hamano
@ 2013-03-28 16:34 ` Jeremy Rosen
2013-03-28 19:29 ` Thomas Taranowski
2013-03-29 5:47 ` Junio C Hamano
0 siblings, 2 replies; 7+ messages in thread
From: Jeremy Rosen @ 2013-03-28 16:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Taranowski, git, David A. Greene, Stephen Smith
>
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git subtree oddity
2013-03-28 16:34 ` Jeremy Rosen
@ 2013-03-28 19:29 ` Thomas Taranowski
2013-03-28 19:44 ` Thomas Taranowski
2013-03-29 5:47 ` Junio C Hamano
1 sibling, 1 reply; 7+ messages in thread
From: Thomas Taranowski @ 2013-03-28 19:29 UTC (permalink / raw)
To: Jeremy Rosen; +Cc: Junio C Hamano, git, David A. Greene, Stephen Smith
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git subtree oddity
2013-03-28 19:29 ` Thomas Taranowski
@ 2013-03-28 19:44 ` Thomas Taranowski
0 siblings, 0 replies; 7+ messages in thread
From: Thomas Taranowski @ 2013-03-28 19:44 UTC (permalink / raw)
To: Jeremy Rosen; +Cc: Junio C Hamano, git, David A. Greene, Stephen Smith
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git subtree oddity
2013-03-28 16:34 ` Jeremy Rosen
2013-03-28 19:29 ` Thomas Taranowski
@ 2013-03-29 5:47 ` Junio C Hamano
1 sibling, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2013-03-29 5:47 UTC (permalink / raw)
To: Jeremy Rosen; +Cc: Thomas Taranowski, git, David A. Greene, Stephen Smith
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-03-29 5:47 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-28 3:12 git subtree oddity Thomas Taranowski
2013-03-28 13:34 ` Stephen Smith
2013-03-28 16:03 ` Junio C Hamano
2013-03-28 16:34 ` Jeremy Rosen
2013-03-28 19:29 ` Thomas Taranowski
2013-03-28 19:44 ` Thomas Taranowski
2013-03-29 5:47 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.