From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27807 invoked by alias); 22 Jan 2014 07:37:15 -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 27788 invoked by uid 89); 22 Jan 2014 07:37:14 -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 07:37:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2524C11655C; Wed, 22 Jan 2014 02:37:09 -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 zLmPga5aWaw6; Wed, 22 Jan 2014 02:37:09 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id BC108116523; Wed, 22 Jan 2014 02:37:08 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 9BC46E059C; Wed, 22 Jan 2014 11:37:09 +0400 (RET) Date: Wed, 22 Jan 2014 07:37:00 -0000 From: Joel Brobecker To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: reject merges on gdb release branches? Message-ID: <20140122073709.GE4762@adacore.com> References: <20140122051133.GB4762@adacore.com> <52DF5B39.1020209@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52DF5B39.1020209@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-01/txt/msg00847.txt.bz2 > > I propose we do the same for the gdb-7.7 branch, and generally > > speaking on all GDB release branches, just to make sure that > > people don't accidently push a merge when they meant to cherry-pick. > > Thoughts? > > My git knowledge is too poor to understand this. How does people push > a merge? My workflow is to cherry-pick approved patches from one branch > to master, and git push. I thought that is the only way to push > commits to master. Am I missing something? You are doing thing correctly. Another way to do things, if you have a large number of commits to push, is to "git rebase your-branch master; git checkout master; git merge your-branch", which should result in a "fast-forward merge" (which is actually not technically a merge). For more info, I really recommend you read a book such as "Pro Git", as understanding the models behind git is a worthwhile investment. The purpose of this proposal is to make sure that people don't do "git merge my-commit-on-master" and push that to the release branch. This would have catastrophic consequences, as it would bring into the branch all commits on master since we created the release branch. Not what the contributor wanted, but very easy to do if you don't know git well enough. -- Joel