Re: git-subtree

[greened@obbligato.org (David A. Greene)]

Jeff King <peff@peff.net> writes:

> I think this is also somewhat different in that git-subtree has a
> multi-year history in git that we may want to keep. So it is more

I agree there may be some value in preserving this history.

> The biggest decision is whether or not to import the existing history.

I agree.  I will leave that decision to the more experienced git
developers.  I'm happy to work either way.

> If we want to throw away the existing history, then I think you end up
> doing the same munging as the latter option above, and then just make a
> single patch out of it instead of a merge.

Right.  That's the approach I've taken for now but it's easy to switch.
There aren't that many changes.

> I don't use git-subtree, but just glancing over the repo, it looks like
> that munging is mostly:
>
>   1. git-subtree.sh stays, and gets added to git.git's top-level Makefile

Done.

>   2. the test.sh script gets adapted into t/tXXXX-subtree.sh

Done.

>   3. git-subtree.txt goes into Documentation/

Done.

>   4. The rest of the files are infrastructure that can go away, as they
>      are a subset of what git.git already contains.

Done.

I have a patch that does all of the above but it is one monolithic blob.
Like I said, the changes aren't extensive so it's easy for me to change
strategies.

> I'd favor keeping the history and doing the munge-overlay thing.

Ok, that sounds fine to me.  I'll do that in a private branch.  What
should I send as patches to the mailing list?  I'm assuming we don't
want [PATCH 235/12342], etc. sent to the list chronicling the entire
history.  :)

> Although part of me wants to join the histories in a subtree so that we
> can use "git subtree" to do it (which would just be cool),

Heh.  I thought about that too.  :)

> I think the resulting code layout doesn't make much sense unless
> git-subtree is going to be maintained separately.

Yeah, I agree.

                                -Dave