Re: little conundrum

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Thu, Nov 03, 2005 at 06:41:20PM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> told me that...
> Since I don't actually have a list of the files, I thought I would establish 
> these automatically by going into each directory and doing a cg-init.  So I 
> now have two disjoint repositories each with their source tree in it.
> 
> My next thought was to add a branch to one of them and then pull the resultant 
> code over and merge it using cg-branch-add followed by a cg-update.  But when 
> I do that it complains that there is no common base.  
> 
> I tried creating an empty directory and separately merging the two versions 
> with it, so that I have a common parent, but whatever I do, I can't get one 
> of those nice little gitk diagrams that has any linkage between the two 
> versions of the source code.

The empty directory is the good approach to do the merge, but you are
going to get a huge number of conflicts. Anyway, this is probably the
most sensible behaviour for cg-merge, so I added cg-merge -j which does
exactly that - use empty tree as a base for three-way merge.

But you actually do not want to do a merge, but:

	$ cd original-version
	$ cg-init
	$ cd ../modified-version
	$ cg-init
	$ cg-branch-add orig ../original-version
	$ cg-fetch orig
	$ echo `cg-object-id` `cg-object-id orig` >.git/info/grafts

Voila, now your commit in 'modified' has the commit in 'original' as its
parent.

PS: And to be able to even commit the cg-merge -j, I had to back out the
git-read-tree -u usage in cg-Xlib's tree_timewarp, which made it racy as
hell - basically, it could be argued that it working _properly_ would be
a race now. Besides, keeping local changes wouldn't work, and stuff.
cg-admin-uncommit was painfully broken.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.