Re: git subtree issues

[Avery Pennarun <apenwarr@gmail.com>]

On Mon, Nov 2, 2009 at 11:56 PM, morgflast <daniel@sibblingz.com> wrote:
> git pull -s subtree vw_extensions master remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (3/3), done.
> remote: Total 3 (delta 2), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From git@github.com:sibblingz/vw_extensions
>  * branch            master     -> FETCH_HEAD
> Already uptodate!
> Merge made by subtree.
>
> However, when I looked at the README file in the first project, the changes
> weren't there.  I was wondering if anyone might have any suggestions about
> what to do.

Hmm, the output certainly wasn't very helpful :(

Usually what "already uptodate" means is that the commit it merged
didn't actually cause any changes.  Is it possible there's another
README file that already contained this change?

The other problem with subtree merge is that it tries to *guess* which
subtree you want to merge, which unfortunately fails almost as often
as it succeeds.  If it guessed incorrectly, it might have thrown away
all the directories except one that didn't change at all.  If this is
the problem, I don't have an easy fix; my git-subtree command (which
makes it a bit easier to do the things you're trying to do in your
email) suffers from this too.  Eventually I was thinking of giving in
and making subtree merge properly configurable, but I haven't had
time.

Or maybe this is a totally different problem.  What do you get from:

  git diff --stat $(git merge-base HEAD^ FETCH_HEAD) FETCH_HEAD

?

Avery