I work on project which uses svn for CVS and about 5-6 months ago we forked branch version_1_9_1 from trunk. Now I have to merge them.
To ease my burden with svn, I wanted to try git for merging, so I followed instructions at: http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html
I end up using following commands:
git svn clone -s hxxp://svn/repo/project project (this takes avout 20min for +30k commmits)
git checkout -b version_1.9.1 remotes/version_1_9_1
git checkout -b the_trunk trunk
git merge version_1.9.1
but when I do 'git mergetool' for, lets say file web.xml, meld opens dialogs for LOCAL and REMOTE, but BASE -file is missing.
While meld dialogs are still open, check which files there are, and get following list:
web.xml
web.xml.BACKUP.12480.xml
web.xml.LOCAL.12480.xml
web.xml.REMOTE.12480.xml
So, for my understanding there should be also file called web.xml.BASE.12480.xml, but its missing.
Result is same no matter if diff3 is activated or de开发者_高级运维activated.
This lead me to think that there is something wrong with cloning... So I executed following commands in clean directory:
git svn clone -s hxxp://svn/repo/project project
gitk
git checkout -b version_1.9.1 remotes/version_1_9_1
gitk
git checkout -b the_trunk trunk
gitk
(Btw. Im doing this on ubuntu 11.04)
Each time I ran gitk, I see flat "hierarchy", where all svn commits are after another. So if I understand this correctly, there is something wrong with "git svn clone", as git cannot find common ancestor for trunk and branch version_1.9.1.
Can anyone point me to right direction with this issue?
Thanks for reading.
Problem was with svn branch. It was forked from trunk so that there was no connection between them.
To check that I used:
$ git svn clone -s hxxp://svn/repo/project project
$ git checkout -b the_trunk remotes/trunk
$ git checkout -b version_1.9.1 remotes/version_1_9_1
$ git branch
master
the_trunk
version_1.9.1
$ git merge-base the_trunk version_1.9.1
merge-base didnt print anything, which tells that those two branches had no relation.
I guess there is many ways to fix this problem. Since Im very new with git, I couldn't figure out any clever way to use gits potential, so I went kind of brute force way:
- I searched last commit in trunk from where version_1_9_1 was forked.
- created new git branch from that point
- replaced all content from this fresh branch with version_1_9_1 contents
- merged it to trunk
- had fun with merge conflicts (seriously, it was so much more easy than what svn would have offered).
Below are commands to do 5 steps above:
$ gitk <= to find git revision id of forked commit, lets say its 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout the_trunk
$ git branch fake_version_1.9.1 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout version_1.9.1
$ mkdir ../temp
$ cp -r projectfiles ../temp <= remember not to copy .git directory
$ git checkout fake_version_1.9.1
$ rm -r projectfiles
$ cp -r ../temp/* .
$ git commit -a
$ git checkout the_trunk
$ git merge fake_version_1.9.1
$ git mergetool <= google "git mergetool" for instruction to setup tool for conflicts, I used p4merge
$ git commit -a
$ git svn dcommit
Over all, I was very happy with this merge. It took some time to figure out that those two branches were not connected to each other, which prevented git merge from producing .BASE file. Generating fake branch allowed git to produce .BASE file, which made merge much more easy: Total files changed: 390 files
Merge conflicts without fake branch: 220 files vs. Merge conflicts with fake branch: 68 files
Also, after going throuhg whole merge, I started to wonder would merge without fake branch had even been possible - atleast in some reasonable time frame.
Thanks for reading.
精彩评论