Re: Please undo "Use git-merge instead of git-resolve in git-pull"

From: Petr Baudis <pasky@suse.cz>
Date: Sep 23, 2005, 00:28 UTC
Message-ID: <20050923002844.GO21019@pasky.or.cz>
In-Reply-To: <Pine.LNX.4.58.0509211902010.2553@g5.osdl.org>

Dear diary, on Thu, Sep 22, 2005 at 04:10:08AM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

> But cogito at least _used_ to have some special logic for moving patches
> forward.

Yes, but it is used only in case of fast-forward commits.

Show 14 quoted lines

> git-resolve-script never had that - it only ever did the per-file
> three-way merge, and refused to touch dirty state except for the
> "everything stays the same" case.
> 
> Oh. I'm looking at the current cg-merge thing, and I think I see the
> problem: it's doing
> 
> 	git-checkout-index -f -u -a
> 
> at the end. That's not only unnecessary, since it uses the "-u" flag to 
> "git-read-tree", but it will force an overwrite of the working tree, and 
> is thus actively incorrect.
> 
> Pasky?

Oops. How brown-paper-bag-ish. Thanks for pointing this out, that was obviously horribly wrong, and it was indeed apparently happily trashing all the local changes. I've removed it, and added proper handling for cases when conflicts arise from merge over a tree with local changes - that was troublesome since cg-commit after resolving the conflicts would commit the local changes too. It won't anymore, and cg-status will mark those files appropriately. Woohoo.

I've also added a rather elaborate regression testing for cg-merge, so I hope that will help catch any future breakages. Hmm, I have to say that while I find writing those tests incredibly boring and annoying, it is pretty nice when I already have them. ;-)

This fix alone is worthy a release, so I'll do one tomorrow.

-- 
				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.