Re: cg-update with local uncommitted changes

[Dan Holmsand <holmsand@gmail.com>]

Petr Baudis wrote:
> Dear diary, on Tue, May 31, 2005 at 12:31:28AM CEST, I got a letter
> where Dan Holmsand <holmsand@gmail.com> told me that...
>>This patch would make cg-merge and cg-admin-uncommit refuse to do 
>>anything if there are conflicting uncommitted changes. Note: this only 
>>applies to fast-forward merging, as cg-merge otherwise bails out if 
>>there are *any* uncommitted changes (which is perhaps going to far).
> 
> 
> Well, non-fast-forward cg-merge will do cg-commit and it would blend the
> unrelated previously uncommitted changes into that, which is not what
> you want.

cg-merge should obviously only commit the files touched by the 
"slow-forward" merge (note: this is not a big deal for me, I have no 
problem with cogito saying "no" once too often. It's when it tries and 
fails that trouble starts).

>>[PATCH] Make tree_timewarp safe, by refusing to handle conflicts.

> I don't really think this makes any sense. What do you then do when you
> want to do some merging of the local uncommitted changes and upstream
> update?

I've never really wanted to do that. I commit, then merge.

> How have you been bitten, and how could we destroy the local changes?
> You get rejects and patch will be pretty vocal about it, so then you
> just go and resolve them. The correct direction is to make it do a
> three-way merge, not make it do no merge at all.

Huh? When I get to the patch rejects, the merge will have happened and 
the local changes pretty much be gone forever. And it's really easy to 
miss the .rej files altogether.

I'd much prefer not having to worry before doing cg-merge/update, then 
to have to salvage old stuff from .rej files. And three-way merges don't 
really solve this; they may work more often, but when they fail, data is 
potentially lost. Why take the chance?

/dan