From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31459 invoked by alias); 24 Jan 2014 11:55:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 31449 invoked by uid 89); 24 Jan 2014 11:55:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 24 Jan 2014 11:55:48 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 38EAF1165D4; Fri, 24 Jan 2014 06:55:46 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8Simsp-EZsEo; Fri, 24 Jan 2014 06:55:46 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C50641165CF; Fri, 24 Jan 2014 06:55:45 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 30CFBE0EF0; Fri, 24 Jan 2014 15:55:48 +0400 (RET) Date: Fri, 24 Jan 2014 11:55:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: will.newton@linaro.org, ricard.wanderlof@axis.com, gdb-patches@sourceware.org Subject: Re: reject merges on gdb release branches? Message-ID: <20140124115548.GO4762@adacore.com> References: <20140124080703.GL4762@adacore.com> <83eh3xep43.fsf@gnu.org> <83a9eleksf.fsf@gnu.org> <838uu5eju2.fsf@gnu.org> <20140124105807.GM4762@adacore.com> <837g9peirg.fsf@gnu.org> <20140124113014.GN4762@adacore.com> <8361p9ehht.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8361p9ehht.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-01/txt/msg00935.txt.bz2 > I'm not talking about review: for review we send and receive diffs, > not commits with their metadata. I'm talking about the history DAG > after the commit and the push. And, as you well know, a merge that > causes conflicts requires a commit after resolving those conflicts. I don't understand what you mean, anymore. > > Sure. Attached is a gittk screenshot. > > And what exactly are the difficulties with that? I can guaranty you that most people will find this non-linear history at best hard to follow, at worst plain confusing. I consider myself relatively well versed in git, and yet I consider this type of history to be fairly hard to follow. While you do not seem to have trouble with it, you have to think about the others. > > I'll have to say that this discussion did reinforce my feeling that > > the current rule has more benefits than drawbacks. > > Sure, since benefits are yours, while drawbacks are mine ;-) > > I'm asking to free me from the tyranny of this rule. You are free to > apply it in your work, but I still see no reasons to force me. You > are used to rebase, so you think a DAG with merges is somehow more > complicated; it isn't. We'll have to agree to disagree, then (and I use merges routinely, so I think I also have a good handle on them). The problem I have with your request is that we're trading a one-off operation (merge vs rebase) against a history that is necessarily more complicated. And most, if not all people who expressed an opinion, confirmed that. I apologize in advance, but I have to disengage from this discussion. I think I've exposed my arguments, and have nothing else to add. As I said, I will live with the outcome, whatever it is. -- Joel