From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21726 invoked by alias); 24 Jan 2014 10:58:09 -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 21631 invoked by uid 89); 24 Jan 2014 10:58:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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 10:58:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id AA28A1165CF; Fri, 24 Jan 2014 05:58:05 -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 l-fZizDo6e50; Fri, 24 Jan 2014 05:58:05 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 28A4F1165C2; Fri, 24 Jan 2014 05:58:05 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 426D2E0EF0; Fri, 24 Jan 2014 14:58:07 +0400 (RET) Date: Fri, 24 Jan 2014 10:58:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: Will Newton , ricard.wanderlof@axis.com, gdb-patches@sourceware.org Subject: Re: reject merges on gdb release branches? Message-ID: <20140124105807.GM4762@adacore.com> References: <83wqhqekpp.fsf@gnu.org> <83ha8tersb.fsf@gnu.org> <20140124080703.GL4762@adacore.com> <83eh3xep43.fsf@gnu.org> <83a9eleksf.fsf@gnu.org> <838uu5eju2.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838uu5eju2.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-01/txt/msg00931.txt.bz2 > It is helpful to anyone who wishes to understand the sequence of > events that led to a certain line being what it is. Merges are in > important part of that. E.g., suppose that a merge produced a > conflict whose resolution mistakenly introduced a bug. If you > eliminate the merge, you will be unable to understand the reasons for > the buggy change, at least not easily. If there are conflicts between your branch and the master branch, and those conflicts are not trivial to resolve, the commits needs to be reviewed again. Otherwise, you would essentially be pushing an unreviewed commits (the merge commit). > Anyway, we are going in circles. I'm not trying to convince you to > change your workflow, I'm asking to allow me to keep mine. But this is at the cost of everyone else finding it more difficult afterwards each time they consult the history. -- Joel