From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SaNQH-00047x-2t for garchives@archives.gentoo.org; Fri, 01 Jun 2012 08:41:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31E01E05FA; Fri, 1 Jun 2012 08:41:10 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by pigeon.gentoo.org (Postfix) with ESMTP id CB8DBE05F1 for ; Fri, 1 Jun 2012 08:40:24 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so316549wib.10 for ; Fri, 01 Jun 2012 01:40:24 -0700 (PDT) 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:content-transfer-encoding; bh=vz6jnLyBVFpix6vWjorux9bWQ5t48I7ZwdU3OeWeTsY=; b=Fcv0MFB8u3zKCUSF5qZGNQZqPyAVQCcbMhTKZAtykv+67WVnmekr6W/V/VkUJ655Or TBUbaELxZe01JKb40zBSAPLQxBSpbq9pia55Q9wTXXC9kGqVZAkzjvhMi2CrguWodchB 79v7l+s2UAFjpGZejPPzod4rWBS0CO7y3jcmhNkJthR32Te2zw00ROy/GRlTsZsLIN5F lzlGkMee4PpoaJD4PxcYFlliz4p2lgz6XYOUMFM3dGI0hcBzbG2YR1Zb900Gry+mR+Vs dmd7qsP2vJ3dO/pcsucL5uATwzGpBExkkv89cp5PyViVSRV7i4tTOz4xYSq8P961Ku9J 6Jdg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.144.139 with SMTP id n11mr1577003wej.30.1338540021285; Fri, 01 Jun 2012 01:40:21 -0700 (PDT) Received: by 10.194.60.167 with HTTP; Fri, 1 Jun 2012 01:40:21 -0700 (PDT) In-Reply-To: References: <4FBCDB3D.1070009@gentoo.org> Date: Fri, 1 Jun 2012 20:40:21 +1200 Message-ID: Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 92f374c4-ad47-4334-8a9c-9bb39f03ba0e X-Archives-Hash: 5ddd4c0df1face26642a376ae79a8931 On 1 June 2012 20:16, Dirkjan Ochtman 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 happ= en. 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 =C2=A0=C2=A0 | \|/ \--->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. --=20 Kent perl -e=C2=A0 "print substr( \"edrgmaM=C2=A0 SPA NOcomil.ic\\@tfrken\", \$_= * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz