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 1SaN4E-0001Ja-Hd for garchives@archives.gentoo.org; Fri, 01 Jun 2012 08:18:42 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5F917E05F1; Fri, 1 Jun 2012 08:18:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 9E386E05BE for ; Fri, 1 Jun 2012 08:17:18 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: djc) by smtp.gentoo.org (Postfix) with ESMTPSA id D411E1B401A for ; Fri, 1 Jun 2012 08:17:17 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so302374wib.10 for ; Fri, 01 Jun 2012 01:17:15 -0700 (PDT) Received: by 10.216.211.131 with SMTP id w3mr1444914weo.163.1338538635295; Fri, 01 Jun 2012 01:17:15 -0700 (PDT) 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.168.82 with HTTP; Fri, 1 Jun 2012 01:16:55 -0700 (PDT) In-Reply-To: References: <4FBCDB3D.1070009@gentoo.org> From: Dirkjan Ochtman Date: Fri, 1 Jun 2012 10:16:55 +0200 Message-ID: Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: f0de7dd9-c5b2-4e86-bda6-05da4ac89e4f X-Archives-Hash: bf62400debbc2bbf56ca81079ec7f40f On Thu, May 31, 2012 at 6:49 PM, Robin H. Johnson wrote: > Discussion on merge policy. Originally I thought we would disallow merge > commits, so that we would get a cleaner history. However, it turns out that if > the repo ends up being pushed to different places with slightly different > histories, merges are absolutely going to be required to prevent somebody from > having to rebase at least one of their sets of commits that are already pushed. 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