From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleh Krehel Subject: Re: Merge branch 'maint' Date: Fri, 11 Sep 2015 18:15:10 +0200 Message-ID: <87wpvxexv5.fsf@gmail.com> 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]:34740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaQyG-0006W3-4e for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 12:14:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaQyB-0008Ah-5d for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 12:14:40 -0400 Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:38435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaQyA-0008Aa-Tb for emacs-orgmode@gnu.org; Fri, 11 Sep 2015 12:14:35 -0400 Received: by wiclk2 with SMTP id lk2so64010875wic.1 for ; Fri, 11 Sep 2015 09:14:34 -0700 (PDT) Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id hr17sm1380182wib.16.2015.09.11.09.14.33 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 11 Sep 2015 09:14:33 -0700 (PDT) In-Reply-To: (Stefan Nobis's message of "Fri, 11 Sep 2015 17:25:53 +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 Stefan Nobis writes: > 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? Of course I do: it's prettier. My problem is that I don't see the advantages that the other approach brings, I only see that it takes away the prettiness. > 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. Org's git history doesn't look complex at all: the commits are pretty much synchronous and applied to master and maint at the same time. Basically, Org's history is already linear, it's just hard to see it behind the ugly bookkeeping. Oleh