From: David Bremner <david@tethera.net>
To: Jameson Graef Rollins <jrollins@finestructure.net>,
	Pieter Praet <pieter@praet.org>, notmuch@notmuchmail.org
Subject: Re: revised patch for gmime init, with test.
In-Reply-To: <87ty3ziau7.fsf@servo.finestructure.net>
References: <1325306261-21444-2-git-send-email-kaz.rag@gmail.com>
	<1325388169-8444-1-git-send-email-david@tethera.net>
	<871ur4ltnx.fsf@praet.org> <877h0wnu1l.fsf@zancas.localnet>
	<874nw0nfa8.fsf@zancas.localnet>
	<87ty3ziau7.fsf@servo.finestructure.net>
User-Agent: Notmuch/0.11 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Fri, 13 Jan 2012 21:31:05 -0400
Message-ID: <87pqenjciu.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Fri, 13 Jan 2012 12:52:48 -0800, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> 
> Doesn't everything need to be merged into master eventually anyway?  It
> seems to me that unless it's a change that very narrowly targeting an
> issue in a release branch that is not an issue in master, every patch
> will ultimately need to be applied to both.  It doesn't really make
> sense to me to apply a change to one branch and not the other, if they
> will eventually need to be applied to both anyway.

The following two sequences of commands apply the same changes, but
result in a different history graph.

1) notmuch checkout release && git am patch  && \
   notmuch checkout master && git cherry-pick release

2) notmuch checkout release && git am patch  && \
   notmuch checkout master && git merge release

well, they apply the same changes if release was an ancestor of master
when the they both began.