From: Pieter Praet <pieter@praet.org>
To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org
Subject: Re: revised patch for gmime init, with test.
In-Reply-To: <874nw0nfa8.fsf@zancas.localnet>
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>
User-Agent: Notmuch/0.10.2+115~gadd29f6 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-unknown-linux-gnu)
Date: Sat, 14 Jan 2012 09:54:04 +0100
Message-ID: <8762ger7f7.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Fri, 13 Jan 2012 05:05:35 -0400, David Bremner <david@tethera.net> wrote:
> On Thu, 12 Jan 2012 23:46:46 -0400, David Bremner <david@tethera.net> wrote:
> > On Thu, 12 Jan 2012 18:25:38 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > On Sat, 31 Dec 2011 23:22:46 -0400, David Bremner <david@tethera.net> wrote:
> > 
> > > with differing hashes), this has the potential of causing confusion
> > > and/or quite some extra work when debugging using git-bisect(1), so
> > > I'd like to propose that bugfixes for (to-be-)released code are only
> > > applied on the 'maint' branch ('release' in the case of Notmuch),
> > > and then immediately merged back into 'master'.  In fact, this would
> > > preferrably happen after *every* (series of) commit(s) on the 'maint'
> > > branch, to prevent issues like [1].
> > 
> > There is some merit it to this. On the other hand, it makes the history
> > messier.  [1] would have also been prevented by making the patch against
> > the right branch.
> 
> I thought about this a bit more, and I agree that at least the release
> candidates (basically anything tagged on branch release) ought to be
> merged back to master. Since any series of bugfix patches seems to be
> cause for a new release candidate, this should avoid the need to have
> doubly applied patches.
> 

Thanks!

> I'm less convinced about the need to merge every little doc change and
> debian packaging change back to master right away. This might be a
> purely aesthetic objection; [...]

See my previous reply [1].

> [...] I'm not sure if the extra merge commits
> cause any problems for e.g. bisection.
> 

Infrequent merging increases the possibility of bugs due to unforeseen
interactions between commits on different branches, which is likely to
require one to do a multitude of fake merges (`git merge --no-commit')
in order to properly track down the offending commit, so... frequent
merging would actually *prevent* issues when bisecting.


> d


Peace

-- 
Pieter

[1] id:"878vlar7ka.fsf@praet.org"