From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28076 invoked by alias); 24 Jan 2014 14:45:18 -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 28054 invoked by uid 89); 24 Jan 2014 14:45:16 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f171.google.com Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Jan 2014 14:45:15 +0000 Received: by mail-ob0-f171.google.com with SMTP id wp4so3684788obc.16 for ; Fri, 24 Jan 2014 06:45:12 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.103.133 with SMTP id fw5mr12585219obb.43.1390574711978; Fri, 24 Jan 2014 06:45:11 -0800 (PST) Received: by 10.76.105.174 with HTTP; Fri, 24 Jan 2014 06:45:11 -0800 (PST) In-Reply-To: <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> <83wqhpcv4z.fsf@gnu.org> Date: Fri, 24 Jan 2014 14:45:00 -0000 Message-ID: Subject: Re: reject merges on gdb release branches? From: "H.J. Lu" To: Eli Zaretskii Cc: Joel Brobecker , Will Newton , ricard.wanderlof@axis.com, GDB Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00941.txt.bz2 On Fri, Jan 24, 2014 at 6:27 AM, Eli Zaretskii wrote: > [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? I use both rebase and merge. I use merge on hjl/linux/master branch since I need to go back to checkout previous trees on my branch. Rebase won't work for me here. But for hjl/mpx/pltext8 branch, I use rebase since I plan to commit it to master when the work is complete and I don't need to go back in history. I don't care about the history of each commit on master and release branches. Merge will only confuse me. But you can tag your merged commit before rebase or create a branch for it. All history will be there for you and it won't confuse other people. -- H.J.