From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suvayu Ali Subject: Re: Merge branch 'maint' Date: Fri, 11 Sep 2015 15:08:51 +0200 Message-ID: <20150911130851.GH6130@chitra.no-ip.org> References: <87twr37il4.fsf@gmail.com> <87y4gfpkjy.fsf@kyleam.com> <87lhceo8he.fsf@gmail.com> <87mvwtvrkc.fsf@kyleam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaO4a-00076t-Fh for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 09:09:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaO4W-0007qF-Cg for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 09:09:00 -0400 Received: from mail-ig0-x232.google.com ([2607:f8b0:4001:c05::232]:33597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaO4W-0007q7-8X for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 09:08:56 -0400 Received: by igbkq10 with SMTP id kq10so44209224igb.0 for ; Fri, 11 Sep 2015 06:08:55 -0700 (PDT) Received: from chitra.no-ip.org ([2001:610:120:3001:2ad2:44ff:fe4a:b029]) by smtp.gmail.com with ESMTPSA id w2sm212520igl.12.2015.09.11.06.08.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2015 06:08:54 -0700 (PDT) Content-Disposition: inline In-Reply-To: <87mvwtvrkc.fsf@kyleam.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org On Thu, Sep 10, 2015 at 06:26:59PM -0400, Kyle Meyer wrote: > Oleh Krehel writes: > > > Why not just cherry-pick the commits from master onto maint, or the > > other way around? That would result in no merge commits. > > The result of doing that is IMO worse than many merge commits. For each > fix in maint, you'd end up with two commits that are linked only by a > patch id (if there are no conflicts) and perhaps a reference in the > message (e.g., if -x is used and there are no conflicts). Merging > allows you to manage a large set of changes, including conflicts, > between upstream and downstream branches and to be sure about which > commits a branch contains. Indeed! It's one of Git's upsides, why fight it? > I think cherry picking should be limited to one-off cases where a fix > lands in master and then it is later realized that it's needed in maint. Well said. -- Suvayu Open source is the future. It sets us free.