X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=GOqpEr5RF+nJ9QdQ+kANODg/JbpSB9bYx2a+veW8TEk=;
	b=05g6rdsHxltv7TFJesnkduS/W1IFTystmZdHGkURYZgdt80EcOltzDty50Fhiz/zv9
	2GFuobVzksqjtRJq6pisI2376OSncTZR2JVrgxUsBDsa422V8vsU3+j7K7XTo2PVOUBV
	C5izWjrBzcJlyZkR2fNAomfF8DYSCIBhP68g/syhwV/DuqM0dKWBahBI7/h0j8LFjz7k
	LISm8PqFPfilAzRPav0VOSk7e8GNL/L2DEeO7gWVCXkPBSmtqLiLjbEIPLXB42wTpBG1
	WFZufZx2ceAcjn+sLvOKlhiqNlHKDMjWCZwWjtStJxI//1Y07vBANgTTBTbZGXUW3Pcc
	Oavg==
MIME-Version:	1.0
In-Reply-To:	<50AD2FED.4040300@xs4all.nl>
References:	<CACwWb3DJsO8J_zAfcSLK=_4iviZy05ZiKj1TFMUUSA8nxO5TwA AT mail DOT gmail DOT com>
	<CAGde_xOFELRBJZ30utu1x+B-y+8Vo+EDGOKPLqyafO+i3ez0QQ AT mail DOT gmail DOT com>
	<CAC4O8c9Z3zmCeeeVU-=BpYTWv1J+3bBh-YcWyepV3U0nftf=gw AT mail DOT gmail DOT com>
	<50ACF554 DOT 4010204 AT jump-ing DOT de>
	<50AD2FED DOT 4040300 AT xs4all DOT nl>
Date:	Wed, 21 Nov 2012 11:43:40 -0900
Message-ID:	<CAC4O8c9Cn99PQx=XThzFc6yJaY0HR8V6UO584RTvd+VZ30vdyg@mail.gmail.com>
Subject:	Re: [geda-user] branches
From:	Britton Kerin <britton DOT kerin AT gmail DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, Nov 21, 2012 at 10:47 AM, Bert Timmerman
<bert DOT timmerman AT xs4all DOT nl> wrote:
> Markus Hitter wrote:
>>
>> Am 20.11.2012 20:14, schrieb Britton Kerin:
>>
>>> 3. Bob rebases, which breaks something that he doesn't catch
>>
>> > 4. Bob pushes
>> > 5. Its a hard mess to sort out since you don't have any
>>>
>>> working version with Bob's changes in the canonical repository
>>
>>
>> The idea is to rebase not the master branch, but feature/debug branches
>> and cherry-pick the reviewed parts of debug/feature branches into master

I know, I still think its a bad way to do it.

>> until the other branch dissolves into nothing. This way you can bisect in
>> detail on the master branch to find regressions.

You can bisect across branches too, and the working commit will actually be
there somewhere.

>> Merging tends to expose the problem you describe. A merge is like one big
>> commit with all the changes between two branches. When searching
>> regressions, you can go back on only one of the two branches. What, if both
>> branches work fine, but not the combination/merge of both?

Sure rebase looks good if you compare it to *infrequent* merging, which has
its own different and bigger problems.  But compared to frequent small merges
its bad.  It rewrites history and thereby forces you to reorder commits if
you want to reconstruct a working version that got rebased out of existence
before it made it to canonical.

Britton

- Raw text -