Re: git-subtree

Jeff King [off-list ref] 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