Re: git-subtree Next Round Ready
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 28, 2012, 22:45 UTC
- Message-ID
- <7vobrgs5tb.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <87398we3ox.fsf@smith.obbligato.org>
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".