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=content-type:mime-version:subject:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to;
	bh=QFQhc6ulE94cuoJDFEE2NbfIkr+OUVxBpi8qU7YSx78=;
	b=bOZ1kjBaq5VAhgHUuxMW1WOpTpOBkEBMcwfqnJx0lcVJ4//L/ctt9/DrHDVZU3qPWi
	ae2BONLH35dUfGtwqGPaSzV9wTHr6tsqxzsb7EIv9PmtGH6eiA7uRaH92BeW1TcGRzb2
	jk2nxKfwsNyoGw2HiZvkQ5/Phcamn/2Zz3pXt6B8VOu7pZR16v7nU9aUDuxI1edG1mMd
	3Y/QQDIRxHEULR8Fd6nom8E2B75dBnrk7wA8fkwNEf/K+OvKmKhTcribsnVFh2Yls7cD
	ADq3kAAAXhZqHDIGt4B4GVc+yXAmiHIuGkQDdjzsX5er6q4TjezqNuQIgwuHEy4MTjfC
	frqg==
X-Received:	by 10.49.81.237 with SMTP id d13mr14260798qey.44.1377907184940;
	Fri, 30 Aug 2013 16:59:44 -0700 (PDT)
Mime-Version:	1.0 (Apple Message framework v1283)
Subject:	merging versus rebasing (was Re: [geda-user] Thoughts on mechanical CAD interaction...)
From:	Charles Lepple <clepple AT gmail DOT com>
In-Reply-To:	<522086BD.6060405@jump-ing.de>
Date:	Fri, 30 Aug 2013 19:59:43 -0400
Message-Id:	<6288E8C7-BD78-44D2-9E2D-85C7257E0314@gmail.com>
References:	<1377775142 DOT 15398 DOT 1 DOT camel AT pcjc2lap> <4F0C8F27-B063-44CF-9011-63D2B62F3FD9 AT jump-ing DOT de> <3752e7fd48358f6e97a09d34392997aa AT cam DOT ac DOT uk> <D5CCEA61-742E-4726-A779-9ADC45D580B4 AT jump-ing DOT de> <87txi7zqkg DOT fsf AT harrington DOT peter-b DOT co DOT uk> <522086BD DOT 6060405 AT jump-ing DOT de>
To:	geda-user AT delorie DOT com
X-Mailer:	Apple Mail (2.1283)
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id r7UNxkYO024448
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 Aug 30, 2013, at 7:49 AM, Markus Hitter wrote:

> Am 30.08.2013 07:38, schrieb Peter TB Brett:
[...]
>> If you want to mess around with rebasing, use a private repo.  In
>> the main gEDA repositories, merges should be used to show how
>> other developments are incorporated into branches.  Since git makes
>> merges *really easy* I don't feel like it's too much to ask.
> 
> With merging you actually obfuscate the history, because you create
> multiple parallel histories; making well known procedures like
> bisecting more difficult or even impossible.

'git bisect' handles merges well (much better than 'git rebase' handles merges, but that's not really a fair comparison.)

I guess this goes back to what your threshold is for a commit. If you use commits like an auto-save feature but don't test each one, you might as well rebase (in a private repository, of course), coalescing things into smaller numbers of patches.

If each node on your graph of the parallel histories is known to be a good build, you can save time chasing down non-regressions when bisecting.

The rebase operation also makes it harder to programmatically identify whether a certain commit has been incorporated into a branch (since the original hash has been destroyed).

> If we'd create a distinct
> history for every tiny bugfix-branch, we'd end up in a pretty mess.
> This are the reasons why I hope the idea of merging goes away, once
> people get used to Git.

Counterexamples: Buildbot, or just about any project that uses something like the Github pull interface extensively. I think it depends less on what style you choose, and more on whether it fits what the rest of the project does. Given how many commits Peter B. has in the gEDA repository...

-- 
Charles Lepple
clepple AT gmail

- Raw text -