Re: cg-update with local uncommitted changes

From: Petr Baudis <pasky@ucw.cz>
Date: May 31, 2005, 15:58 UTC
Message-ID: <20050531155825.GA7013@pasky.ji.cz>
In-Reply-To: <d7g430$1cq$1@sea.gmane.org>

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

Show 12 quoted lines

> Marcel Holtmann wrote:
> >I also think that it would be great if we cancel the merge if the local
> >changes conflict with the files in the merge. This is how Bitkeeper does
> >it and I think it is the only safe way, because if something fails or
> >rejects we may destroy the local changes.
> 
> I definitely agree (been bitten by patching gone wild a couple of times...).
> 
> 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.

> [PATCH] Make tree_timewarp safe, by refusing to handle conflicts.
> 
> Signed-off-by: Dan Holmsand <holmsand@gmail.com>

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?

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor