Pratyush Yadav <m...@yadavpratyush.com> 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.
