From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12333 invoked by alias); 23 Jan 2014 16:17:27 -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 12315 invoked by uid 89); 23 Jan 2014 16:17:26 -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,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Jan 2014 16:17:24 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MZV00B003FRDU00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Thu, 23 Jan 2014 18:17:21 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZV00B8J3WXEY00@a-mtaout23.012.net.il>; Thu, 23 Jan 2014 18:17:21 +0200 (IST) Date: Thu, 23 Jan 2014 16:17:00 -0000 From: Eli Zaretskii Subject: Re: reject merges on gdb release branches? In-reply-to: To: Ricard Wanderlof Cc: brobecker@adacore.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83wqhqekpp.fsf@gnu.org> References: <20140122051133.GB4762@adacore.com> <83r480f2r2.fsf@gnu.org> <20140122161520.GF4762@adacore.com> <83bnz4ezst.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00908.txt.bz2 > Date: Thu, 23 Jan 2014 08:46:32 +0100 > From: Ricard Wanderlof > CC: Joel Brobecker , "gdb-patches@sourceware.org" > > > I think it's not the merging per se that is a problem, only if it is done > incorrectly, i.e. merging from a branch that was was broken off from > master a long time ago, which brings in a lot of unwanted stuff. There's any number of ways one can make a mistake and screw up master. That cannot be the reason for forcing a particular workflow on everyone, certainly not before any such problems actually happened even once. And I don't understand your fear of unwanted stuff from a divergent branch: what exactly is special about this situation? Surely, examining the diffs before committing and pushing would show what is about to land on master, so where's the danger that doesn't exist in any other commit? > Loosing information about merges from master during a rebase I don't think > is too much of an issue. Once the branch has been rebased to master, any > merges from master would have occurred in the past anyway. The information lost can be important when bisecting later, or more generally researching how a given piece of code or bug entered the code base. It can also be important if I merge between my local branches as part of working on a feature, something that isn't unheard of. Again, I can understand that some people are accustomed to rebasing, and I'm okay with that. But I don't understand why something that is essentially a matter of personal preferences is forced on everyone.