Pratyush Yadav <me@xxxxxxxxxxxxxxxxx> writes: > Assuming I have git.git cloned in ../git (relative to git-gui.git), I > ran: > > git pull -Xsubtree=git-gui ../git $branches > > instead of: > > git merge $branches > > because git-gui's tree doesn't have those commits and branches yet, so > we can't merge straight away. This seems to have worked, but I thought > I'd mention it in case it would cause some subtle problems. I am not sure what your $branches above are referring to, but if you run "git log" in the resulting git-gui repository and see any of the commits that are about git and not git-gui, then it is not a subtle but a grave problem. The reason why git-gui and gitk are separate projects is because they do not want to contaminate their history with stuff that are not related to them (e.g. changes to "git fast-export"). Taking one of the commits Denton found as an example: >> js/misc-git-gui-stuff: 76756d67061076c046973bff2089ad49f5dc2eb6 (by the way, this can also be found by running git log --first-parent --min-parents=2 master -- git-gui in git itself; 02a5f25d956be187bc0 merged it in as its second parent. The second parents of these merges you would find are candidates---you may already have some, and you may need to merge others to your tree; there may be some that are direct updates to git-gui/ part of my tree (which shouldn't have been done but mistakes happen). You should be able to merge this (and all other git-gui topics already in my tree Denton pointed out) to your 'master'. If you then make a trial merge of the result back into my tree with "git merge -Xsubtree=git-gui", it should result in "already up to date", i.e. a noop merge. Thanks.
