Manuel Reimer <manuel.spam@xxxxxxxxxxxxxx> writes: > Hello, > > following situation: > > - Project hosted on GIT. Have a local copy and push to remote server. > - Small addon is hosted on a remote SVN server > - I now cloned the SVN to a local GIT (svn git clone) > - Then I used the instructions from here: > > <http://git-mirror.googlecode.com/git-history/7444c60/howto/using-merge-subtree.html> > > to get the local SVN copy merged into a subdirectory on my project GIT. Anything > worked well. > > To test the worst case, I cloned my project GIT to a new local repository. The > remote connection to the local SVN copy was lost, so I recreated it. It is unclear to me what you meant by "connection" "lost" and "recreated" above, but I am guessing I can ignore them, as long as I take it that you mean by that local mirror from the subversion repository "Bproject" below. > Now, for some reason, I can immediately call > > git pull -s subtree Bproject master > > to pull changes from the SVN copy to the subdir... I didn't have to call "git > read-tree" again. That "how to" may be badly written and this may have been unclear to you but the first four steps are to be done _only once_ to set things up, and after that you need to run only the fifth step whenever you want to update from the Bproject. Could you suggest a better wording to update the doc? The very first "subtree merge" (the one that is recorded with the commit after the read-tree) records all paths from Bproject renamed to elsewhere in the merge result (you can view it with "git show -M $that_merge_commit"), and that is what allows "pull -s" (both the initial one and subsequent ones; indeed the fifth step in the initial round is not any more special than the subsequent round) notice where changes from the Bproject ought to go. -- 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