Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Kent Fredric <kentfredric@...>
Subject: Re: Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 1 Jun 2012 20:40:21 +1200
On 1 June 2012 20:16, Dirkjan Ochtman <djc@g.o> wrote:
> Can you elaborate on why the cleaner history a no-merge policy
> enforces is a good thing? I actually think that seeing merge commits
> might clarify the history; it can be valuable to see that some mistake
> was made in a merge instead, but you can only see that if there's an
> explicit merge commit.
>
> I should note that I come at this from the Mercurial side, where the
> immutability of (public) history has historically carried more value
> than on the git side (and related to that, rebase-like tools were less
> integrated until relatively recently).
>
> Cheers,
>
> Dirkjan
>

One of the perk of fast-forward only histories is merge problems don't happen.

If a commit sequence isn't fast-fowardable, then the submitter has to
rebase it, and a rebased history is a guaranteed clean merge.

It also puts the onus on making the patch sequence mergable on the
contributor of that patch sequence, by forcing them to resolve
conflicts before they can submit their branch for inclusion, and this
is good, because they understand their own changes best, and are the
best person to decide how to deal with conflicts.

The best example of this is 2 people contribute behaviourally
identical code, with different syntax .

In the case of a merge, the person performing the merge has to decide
which one to take, and they might not be the best person to do so. (
And historically, it can be confusing if you look at the parents of
the merge, and find the 2 competing implementations, of which only 1
is relevant )

If you request that a branch is rebased before it is integrated, then
this problem solves itself in a way.

Whoevers implementation gets in the tree first gets in, and then the
second person rebases their branch on top of that.

In the process of performing the rebase, the second person will
discover the precise commit on their side that introduces a conflict,
and be able to decide if they need to replace the existing code
anyway, or if they need to destroy their own code.

And when they're done, their entire commit series should be sane and
logical as if the first persons code was there in the first place
before the second person even started coding.

a--->b--->c---->d--->e--->f
                |                      \|/
                \--->x--->y---->z

Essentially, in this diagram, if d and y are different, but
equivalent, they will cause a collision when merge Z is performed.

By performing a rebase of  the second branch, the logical order becomes

a--->b--->c---->d--->e--->f--->x--->y--->z

And when the rebaser is applying "y", they will notice it is likely
redundant, and the history will become

a--->b--->c---->d--->e--->f--->x--->z

And in both the merge and rebase examples, z will be the same, just
the cognitive overhead of understanding "what the hell happened" in
the latter case is simpler, as the biggest delta between any 2 commits
will be 1 commit worth, whereas in the merge case,  there will be a
huge delta  between the commit before the merge, and the commit after
the merge, and looking at the merge itself diff-wise, you'll be
comparing the aggregate result of 2 entire branches worth of commits,
as opposed to only comparing one small and simple commit with another.


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


References:
Portage Git migration - clean cut or git-cvsserver
-- Michael Weber
Re: Portage Git migration - clean cut or git-cvsserver
-- Alexey Shvetsov
Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Previous by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by date:
lastrite x11-terms/cxterm


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.