From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26910 invoked by alias); 22 Jan 2014 16:15: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 26892 invoked by uid 89); 22 Jan 2014 16:15:23 -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; Wed, 22 Jan 2014 16:15:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E72041165A8; Wed, 22 Jan 2014 11:15:19 -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 740WyTJ7jGnV; Wed, 22 Jan 2014 11:15:19 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 811AD116556; Wed, 22 Jan 2014 11:15:19 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8254DE05D8; Wed, 22 Jan 2014 20:15:20 +0400 (RET) Date: Wed, 22 Jan 2014 16:15:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: reject merges on gdb release branches? Message-ID: <20140122161520.GF4762@adacore.com> References: <20140122051133.GB4762@adacore.com> <83r480f2r2.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83r480f2r2.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-01/txt/msg00865.txt.bz2 > Doesn't that mean you are forcing everybody to rebase before > committing from feature branches? If so, that sounds drastic, and > should have very good reasons. (Apologies if this was already > discussed and decided, but in that case I'd appreciate a pointer.) IIUC, you're asking a general question: Is it OK to do a merge of a feature branch onto another, and then push that branch? The currently situation, as discussed during the transition to git, was that this is not allowed for the "master" branch. Note that a rebase, compared to a merge, is not that much more work, and has the nice property of keeping the history linear. I've been managing patch series of 20+ patches, with regular rebases, without problems. It's something you do anyway in order to submit the patches, so I don't think this is an issue in practice. This proposal is to extend this restriction to all GDB release branches, for the reasons detailed in my reply to Yao. Basically, this is to avoid mistakes resulting us in merging more than what you intended. -- Joel