Avery Pennarun <apenwarr@xxxxxxxxx> wrote:
> On 5/5/08, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
> >
> > `git pull -s subtree mylib` ?
>
> First, I thought: wow! How can that possibly work? These guys are geniuses!
>
> Then I found out that git-merge-subtree is a git builtin, and git.c says this:
>
> { "merge-recursive", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
> { "merge-subtree", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
>
> And then my head exploded. :)
>
> Still scraping the pieces of my brain back off the floor... but does
> this mean the subtree merge strategy would fail exactly like
> merge-recursive when new files are created?
Nope. If you go look at cmd_merge_recursive you will see it has
different behavior based upon the name it was invoked as, even
though it is the same C function and has the same implementation.
If it is started with the name "merge-subtree" it tries to find
a matching subtree prefix to insert in front of all names, or
to remove from all names, such that a merge will correctly fully
include a set of files in a subdirectory, or full pull out a set
of files from a subdirectory.
Junio is the genius that implemented this. Works quite well for
this library->application merge case that I think you were trying
to describe.
--
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
