threads / discuss / 30058

git-subtree Next Round Ready

Subject: git-subtree Next Round Ready

## tl;dr

6 messages between Mar 25, 2012 and Apr 10, 2012.

replies: 5people: 2as markdown or json

greened@obbligato.org· Mar 25, 2012, 22:06 UTC · lore

Ok, I've cleaned things up with git-subtree so the changes I had to the test infrastructure are gone. No changes to upstream are needed to support git-subtree in contrib/ now.

As usual, the branches are here:
git://sources.obbligato.org/git/git.git
gitweb here: http://sources.obbligato.org/?p=git.git;a=summary

There are three branches. master is the usual. "subtree-latest" is my version of git-subtree cleaned up for upstreaming into contrib/. This is the pure git-subtree history, ready to be subtree merged. "subtree-integrated" is a version of upstream git.git with subtree-latest merged as a subtree (done via git-subtree!).

I assume it will be easier to have Junio or another integrator do the subtree merge from subtree-latest in his or her workarea but I provide subtree-integrated so everyone can easily check out what it will look like.

Let me know of anything else you need.
Thanks!
                         -Dave
Junio C Hamano· Mar 28, 2012, 22:45 UTC · re: greened@obbligato.org · lore

Re: git-subtree Next Round Ready

greened@obbligato.org writes:
Show 5 quoted lines
> There are three branches.  master is the usual.  "subtree-latest" is my
> version of git-subtree cleaned up for upstreaming into contrib/.  This
> is the pure git-subtree history, ready to be subtree merged.
> "subtree-integrated" is a version of upstream git.git with
> subtree-latest merged as a subtree (done via git-subtree!).

I do not see the point of your subtree branch, especially after 1f30551 (Set TEST_DIRECTORY, 2012-03-20) where it starts depending on files outside its top-level directory. At that point, the tree ceases to be viable as a standalone project.

I think it would make more sense, from the history viewpoint, to:
 - Stop the history of the "subtree" branch at commit d3a04e0 (Use Test
   Harness, 2012-01-29);
 - Create "for-upstream" branch that is a fork of 1.7.10 (when tagged);
 - On "for-upstream" branch, add all the files from d3a04e0 (Use Test
   Harness, 2012-01-29) to contrib/subtree, and record it as a merge
   between 1.7.10 and d3a04e0 (you can use subtree merge for this); and
   finally
 - Replay the commits between d3a04e0 and the tip of your current
   "subtree" branch on top of "for-upstream".
And then have me pull the "for-upstream" branch.

Further development after that point can continue in-tree just like any other contrib subsystems like "completion/" and "fast-import/git-p4".

greened@obbligato.org· Apr 1, 2012, 18:00 UTC · re: Junio C Hamano · lore

Re: git-subtree Next Round Ready

Junio C Hamano <gitster@pobox.com> writes:
> I do not see the point of your subtree branch, especially after 1f30551
> (Set TEST_DIRECTORY, 2012-03-20) where it starts depending on files
> outside its top-level directory. At that point, the tree ceases to be
> viable as a standalone project.

The point of the branch was to provide an easy reference to subtree merge into the main git repository. I have no intention of keeping a separate git-subtree project.

Show 16 quoted lines
> I think it would make more sense, from the history viewpoint, to:
>
>  - Stop the history of the "subtree" branch at commit d3a04e0 (Use Test
>    Harness, 2012-01-29);
>
>  - Create "for-upstream" branch that is a fork of 1.7.10 (when tagged);
>
>  - On "for-upstream" branch, add all the files from d3a04e0 (Use Test
>    Harness, 2012-01-29) to contrib/subtree, and record it as a merge
>    between 1.7.10 and d3a04e0 (you can use subtree merge for this); and
>    finally
>
>  - Replay the commits between d3a04e0 and the tip of your current
>    "subtree" branch on top of "for-upstream".
>
> And then have me pull the "for-upstream" branch.
Ok, that sounds fine to me.
> Further development after that point can continue in-tree just like any
> other contrib subsystems like "completion/" and "fast-import/git-p4".
Yep, sounds good!
                         -Dave
greened@obbligato.org· Apr 10, 2012, 03:34 UTC · re: Junio C Hamano · lore

Re: git-subtree Next Round Ready

Junio C Hamano <gitster@pobox.com> writes:
Show 14 quoted lines
> I think it would make more sense, from the history viewpoint, to:
>
>  - Stop the history of the "subtree" branch at commit d3a04e0 (Use Test
>    Harness, 2012-01-29);
>
>  - Create "for-upstream" branch that is a fork of 1.7.10 (when tagged);
>
>  - On "for-upstream" branch, add all the files from d3a04e0 (Use Test
>    Harness, 2012-01-29) to contrib/subtree, and record it as a merge
>    between 1.7.10 and d3a04e0 (you can use subtree merge for this); and
>    finally
>
>  - Replay the commits between d3a04e0 and the tip of your current
>    "subtree" branch on top of "for-upstream".
All right, this should be ready to go.
git clone git://sources.obbligato.org/git/git.git
Branch is "for-upstream."
Also accessible via gitweb.
                           -Dave
Junio C Hamano· Apr 10, 2012, 16:02 UTC · re: greened@obbligato.org · lore

Re: git-subtree Next Round Ready

greened@obbligato.org writes:
Show 5 quoted lines
> All right, this should be ready to go.
>
> git clone git://sources.obbligato.org/git/git.git
>
> Branch is "for-upstream."

I'll pull this directly to 'master' as this touches nothing outside contrib/subtree/ directory.

If this will eventually become part of git-core, the default set for $(prefix) in contrib/subtree/Makefile may want to watch what we set in the toplevel Makefile, but minor things like that can be tweaked in-tree.

Thanks.
greened@obbligato.org· Apr 10, 2012, 18:12 UTC · re: Junio C Hamano · lore

Re: git-subtree Next Round Ready

Junio C Hamano <gitster@pobox.com> writes:
> I'll pull this directly to 'master' as this touches nothing outside
> contrib/subtree/ directory.
Thanks!
> If this will eventually become part of git-core, the default set for
> $(prefix) in contrib/subtree/Makefile may want to watch what we set in the
> toplevel Makefile, but minor things like that can be tweaked in-tree.

Yeah, I thought about that but I didn't know the best way to grab the default from the Makefile.

It should be easy to move this to git-core. The top-level Makefile should just work when the files are moved out of contrib.

Thanks for integrating this. Then I can look at Herman's changes and then maybe we can talk about what we need to do to move this to git-core.

                             -Dave

← back to recent threads