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=DQmHLiV5/iaZLFOOnznn9faADV3oaO5ojj+ZHT4A+bw=;
        b=F1aXKJfl1Lg3nzHkdNaCGH9oiPAA9rqI9vNFlFKvevblx/kaJ+XL++P6dFjd/sw6f+
         eDWnQptH2Z79z9if2DnVGa5P5nirBTN8zUDkSr6yonnCmi2238SaU9L0O8zOmfxBIyHB
         eCZORF22Syqb+zipdgZMVLe6wQ5OhTn7Z+kHzsKknlrlY7LoM0NUSiYE1gL3v5BGXf3n
         96g7jS2l6Ylf1an11fn0dc4pno7c1C+E+Eeq8rWeVxgB4ytnVuvX6T+jpWi2ml40jCUD
         PWc8kj/F4y15C0Ds0JTpQDY6SD5KI95HVSwc8O7+hMzSuaS3GPxrrrM4X6UBOsjwnC5V
         0u1g==
MIME-Version: 1.0
X-Received: by 10.180.36.133 with SMTP id q5mr7188369wij.0.1377970407562; Sat,
 31 Aug 2013 10:33:27 -0700 (PDT)
In-Reply-To: <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>
	<6288E8C7-BD78-44D2-9E2D-85C7257E0314 AT gmail DOT com>
Date: Sat, 31 Aug 2013 09:33:27 -0800
Message-ID: <CAC4O8c-fkATqRA1WxpBp1TTOuaTrrEurVWMH6B+NZ=FpOaaZPQ@mail.gmail.com>
Subject: Re: merging versus rebasing (was Re: [geda-user] Thoughts on
 mechanical CAD interaction...)
From: Britton Kerin <britton DOT kerin AT gmail DOT com>
To: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary=e89a8f5030c6a78eb004e541bc92
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
Precedence: bulk

--e89a8f5030c6a78eb004e541bc92
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 30, 2013 at 3:59 PM, Charles Lepple <clepple AT gmail DOT com> wrote:

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

Indeed, if its all Peter it doesn't matter and he should do what he damn
well pleases.
rebase is evil though.  It rewrites history and can easily get you in a
situation where
a once-working-for-somebody revision doesn't exist anywhere in the
canonical repository.

Britton

--e89a8f5030c6a78eb004e541bc92
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Aug 30, 2013 at 3:59 PM, Charles Lepple <span dir=3D"ltr">&=
lt;<a href=3D"mailto:clepple AT gmail DOT com" target=3D"_blank">clepple AT gmail DOT com=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Aug 30, 2013, at 7:49 AM, Markus Hitter w=
rote:<br>
<br>
&gt; Am 30.08.2013 07:38, schrieb Peter TB Brett:<br>
[...]<br>
&gt;&gt; If you want to mess around with rebasing, use a private repo. =A0I=
n<br>
&gt;&gt; the main gEDA repositories, merges should be used to show how<br>
&gt;&gt; other developments are incorporated into branches. =A0Since git ma=
kes<br>
&gt;&gt; merges *really easy* I don&#39;t feel like it&#39;s too much to as=
k.<br>
&gt;<br>
&gt; With merging you actually obfuscate the history, because you create<br=
>
&gt; multiple parallel histories; making well known procedures like<br>
&gt; bisecting more difficult or even impossible.<br>
<br>
&#39;git bisect&#39; handles merges well (much better than &#39;git rebase&=
#39; handles merges, but that&#39;s not really a fair comparison.)<br>
<br>
I guess this goes back to what your threshold is for a commit. If you use c=
ommits like an auto-save feature but don&#39;t test each one, you might as =
well rebase (in a private repository, of course), coalescing things into sm=
aller numbers of patches.<br>

<br>
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.<br>
<br>
The rebase operation also makes it harder to programmatically identify whet=
her a certain commit has been incorporated into a branch (since the origina=
l hash has been destroyed).<br>
<br>
&gt; If we&#39;d create a distinct<br>
&gt; history for every tiny bugfix-branch, we&#39;d end up in a pretty mess=
.<br>
&gt; This are the reasons why I hope the idea of merging goes away, once<br=
>
&gt; people get used to Git.<br>
<br>
Counterexamples: Buildbot, or just about any project that uses something li=
ke the Github pull interface extensively. I think it depends less on what s=
tyle you choose, and more on whether it fits what the rest of the project d=
oes. Given how many commits Peter B. has in the gEDA repository...<br>
</blockquote><div><br>Indeed, if its all Peter it doesn&#39;t matter and he=
 should do what he damn well pleases.<br>rebase is evil though.=A0 It rewri=
tes history and can easily get you in a situation where<br>a once-working-f=
or-somebody revision doesn&#39;t exist anywhere in the canonical repository=
.<br>
<br>Britton<br></div></div></div></div>

--e89a8f5030c6a78eb004e541bc92--