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

[Petr Baudis <pasky@suse.cz>]

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.

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