Re: merge renamed files/directories?

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 6, 2008, 01:58 UTC
Message-ID: <32541b130805051858u7b8f1cd7qd34fdf50c1f849d0@mail.gmail.com>
In-Reply-To: <20080506014636.GM29038@spearce.org>

On 5/5/08, Shawn O. Pearce <spearce@spearce.org> wrote:

Show 20 quoted lines

> Avery Pennarun <apenwarr@gmail.com> wrote:
>  >
>  > I have a branch called 'mylib' with my library project in its root
>  > directory.  What I wanted was to maintain my library in the 'mylib'
>  > branch, then merge my library into the "libs/mylib" directory of my
>
> > application, which is in the 'myapp' branch. [...]
>
> >
>  > This actually works like magic in git - except when you create a file
>  > in the 'mylib' branch, in which case it gets merged to the wrong path
>  > every single time.  It seems to me like it should be very easy to put
>  > it in the right place instead, making one more interesting use case
>  > possible.
>  >
>  > I realize git-submodule is the way you're supposed to do something
>  > like this, but git-submodule doesn't really do what I want (yet) for
>  > reasons discussed in other threads.
>
> `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?

Have fun,

Avery