Re: git-subtree

greened@obbligato.org (David A. Greene) writes:

quoted

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.  :)

quoted

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 actually did end up doing a subtree merge via git subtree.  It was
more convenient to put it in contrib/ like that as almost everthing
there is in its own subdirectory.

I'm cleaning things up there to remove redundancy, rewrite tests (using
earlier work), etc.  What number should I use for git-subtree tests?
Here are some logical candidates:

        5 - the pull and exporting commands
        6 - the revision tree commands (even e.g. merge-base)
        7 - the porcelainish commands concerning the working tree
        9 - the git tools

git-subtree can pull and export.  It also affects revision trees (it
merges, for example) and is a porcelainish command that affects the
working tree.  It is also a "git tool" of a sort.

I originally put them under t97XX but now that is taken, as is
everything up to and including t99XX.

Anyone have a strong opinion?

Thanks!

                           -Dave