Mail Archives: geda-user/2013/08/31/13:34:16
--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>></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>
> Am 30.08.2013 07:38, schrieb Peter TB Brett:<br>
[...]<br>
>> If you want to mess around with rebasing, use a private repo. =A0I=
n<br>
>> the main gEDA repositories, merges should be used to show how<br>
>> other developments are incorporated into branches. =A0Since git ma=
kes<br>
>> merges *really easy* I don't feel like it's too much to as=
k.<br>
><br>
> With merging you actually obfuscate the history, because you create<br=
>
> multiple parallel histories; making well known procedures like<br>
> bisecting more difficult or even impossible.<br>
<br>
'git bisect' handles merges well (much better than 'git rebase&=
#39; handles merges, but that'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'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>
> If we'd create a distinct<br>
> history for every tiny bugfix-branch, we'd end up in a pretty mess=
.<br>
> This are the reasons why I hope the idea of merging goes away, once<br=
>
> 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'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't exist anywhere in the canonical repository=
.<br>
<br>Britton<br></div></div></div></div>
--e89a8f5030c6a78eb004e541bc92--
- Raw text -