From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Nobis Subject: Re: Merge branch 'maint' Date: Fri, 11 Sep 2015 17:25:53 +0200 Message-ID: References: <87twr37il4.fsf@gmail.com> <87y4gfpkjy.fsf@kyleam.com> <87lhceo8he.fsf@gmail.com> <87mvwtvrkc.fsf@kyleam.com> <87vbbhgo9h.fsf@gmail.com> <87a8stxgcc.fsf@gmail.com> <87lhcdgh6u.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaQDE-0005KY-NB for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 11:26:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaQDA-0005jl-Ox for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 11:26:04 -0400 Received: from basilikum.nobis-admin.de ([89.238.71.130]:47733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaQDA-0005jh-Ge for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 11:26:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basilikum.nobis-admin.de (Postfix) with ESMTP id 1D0F77E0884 for ; Fri, 11 Sep 2015 17:25:59 +0200 (CEST) Received: from basilikum.nobis-admin.de ([127.0.0.1]) by localhost (basilikum.nobis-admin.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChhirEbIMSt4 for ; Fri, 11 Sep 2015 17:25:53 +0200 (CEST) Received: from karotte.fritz.box (unknown [IPv6:2001:4dd0:fb8a:0:e49a:a959:775c:c206]) by basilikum.nobis-admin.de (Postfix) with ESMTPSA for ; Fri, 11 Sep 2015 17:25:53 +0200 (CEST) In-Reply-To: <87lhcdgh6u.fsf@gmail.com> (Oleh Krehel's message of "Fri, 11 Sep 2015 16:32:25 +0200") 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 Oleh Krehel writes: > Would it be so hard for Git to perform a single merge of master into > maint on release, while keeping them separate and cherry-picking > in-between for the sake of a clean linear history? The question is not whether git is capable of doing this (there are ways to accomplish this goal). The true question is: Do you really want a linear history? A linear history may look pretty, but at the same time you loose information. In a big complex project that is also a dependency to another complex project, a bit more ugly bookeeping may make maintenance easier. -- Until the next mail..., Stefan.