Re: Problem with cg-merge

From: Jonas Fonseca <fonseca@diku.dk>
Date: May 29, 2005, 21:15 UTC
Message-ID: <20050529211524.GB32141@diku.dk>
In-Reply-To: <20050529184830.GM1036@pasky.ji.cz>

Petr Baudis <pasky@ucw.cz> wrote Sun, May 29, 2005:

Show 21 quoted lines

> Dear diary, on Sun, May 29, 2005 at 08:17:30PM CEST, I got a letter
> where Marcel Holtmann <marcel@holtmann.org> told me that...
> > > --- 0ca4ae56fa7bbd8d10e2c2791e389bc19977e460/cg-Xlib  (mode:100755)
> > > +++ uncommitted/cg-Xlib  (mode:100755)
> > > @@ -66,7 +66,7 @@
> > >  		# XXX: This may be suboptimal, but it is also non-trivial to keep
> > >  		# the adds/removes properly.  So this is just a quick hack to get it
> > >  		# working without much fuss.
> > > -		cg-diff -r $branch >$patchfile
> > > +		cg-diff >$patchfile
> > >  	fi
> > >  
> > >  	git-read-tree -m "$branch" || die "$branch: bad commit"
> > 
> > this looks better now. Petr, please apply this patch.
> 
> Bah. Well if your imaginary friend in your head told you this is
> obviously just a no-go workaround, (s)he was right for once. You just
> broke cg-admin-uncommit with this one, the real fix is to tell
> tree_timewarp to rollback the tree (or rather rollforth here ;-). This
> way the right branch of this if will be invoked.

Ok, I should have mentioned it was an ugly workaround.

There is another problem I've noticed in the work on the cogito manpages. To make it easier to update the ``external'' patch I maintain I have added the files Documentation/make-cg-asciidoc and Documentation/make-cogito-asciidoc but not actually committed them. That way cg-diff will include them (diffed against /dev/null) which I like very much. However, when I cg-update from my local cogito origin cg-merge will fast-forward using cg-diff which results in rejects when patching the local changes due to the files already existing.

One possibility would be to revert all local changes with the patch generated by cg-diff since most of them will be overwritten anyway. This would remove uncommitted added files but it would probably require use of the GIT metadata to get the fast-forwarding right with modes intact.

-- 
Jonas Fonseca