On Mon, Nov 2, 2009 at 11:56 PM, morgflast <daniel@xxxxxxxxxxxxx> 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@xxxxxxxxxx: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 -- 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