From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12390 invoked by alias); 24 Jan 2014 14:27:24 -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 12251 invoked by uid 89); 24 Jan 2014 14:27:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout26.012.net.il Received: from mtaout26.012.net.il (HELO mtaout26.012.net.il) (80.179.55.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2014 14:27:23 +0000 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0MZW00200SSSE000@mtaout26.012.net.il> for gdb-patches@sourceware.org; Fri, 24 Jan 2014 16:26:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZW004LPTGFYY00@mtaout26.012.net.il>; Fri, 24 Jan 2014 16:26:40 +0200 (IST) Date: Fri, 24 Jan 2014 14:27:00 -0000 From: Eli Zaretskii Subject: Re: reject merges on gdb release branches? In-reply-to: <20140124115548.GO4762@adacore.com> To: Joel Brobecker Cc: will.newton@linaro.org, ricard.wanderlof@axis.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83wqhpcv4z.fsf@gnu.org> 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> <20140124115548.GO4762@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00940.txt.bz2 [Resending because the list rejected the attachment.] > Date: Fri, 24 Jan 2014 15:55:48 +0400 > From: Joel Brobecker > Cc: will.newton@linaro.org, ricard.wanderlof@axis.com, gdb-patches@sourceware.org > > > 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. Sorry about that. What I meant to say was that the merge vs rebase issue is not relevant to patch review. > > > 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. In Emacs development, we don't have any trouble with even more complicated DAG structures. See the attached for a (relatively simple) example. > 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. Why does this issue have to be decided by a majority?