From: Pieter Praet <pieter@praet.org>
To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org
Subject: Re: [PATCH v2] Output unmodified Content-Type header value for JSON
	format.
In-Reply-To: <87vcogs35e.fsf@zancas.localnet>
References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>
	<1321676321-27745-1-git-send-email-dmitry.kurochkin@gmail.com>
	<87sjlktgi6.fsf@zancas.localnet> <87obw6prpd.fsf@gmail.com>
	<87fwfkluh3.fsf@praet.org> <87vcogs35e.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:59:49 +0100
Message-ID: <87zkdqpsl6.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Thu, 12 Jan 2012 23:16:29 -0400, David Bremner <david@tethera.net> wrote:
> On Thu, 12 Jan 2012 18:08:08 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > > - The previous point is a bit of a counterargument to this, but in
> 
> > > I couls separate it.  I made is a single patch to avoid having a
> > > revision with broken emacs UI (and tests).
> > > 
> 
> > I'd like to propose to always apply patch series on a *topic* branch
> > which would then be merged back into 'master', thus avoiding this issue
> > altogether whilst making it more obvious which patches belong together
> > (eg. for easier cross-referencing with the ML).
> 
> Hi Pieter;
> 
> Sorry, I must have lost the thread somewhere.  What application are you
> thinking about, and what issue do you think that topic branches avoid?
> 

No specific application;

In the case of patch series, it may occur that an individual commit
leaves the code in a broken state.  One might argue that devs need to
ensure that the project builds cleanly at every commit, but this can be
prohibitively time-consuming or even simply impossible due to the need
to keep changes atomic and area-specific (eg. changes to the binary and
the Emacs UI should be separate commits irrespective of their relation).

So it would make sense to consistently apply (certain, or perhaps all?)
patch series on an ad-hoc branch which would then be merged back into
'master', instead of being directly applied on 'master'.

Aside from preventing broken builds (as was Dmitry's reason to consolidate
a series touching on multiple distinct "spheres" of the code into a single
patch), series of related commits would also be clearly delineated/clustered,
facilitating source archaeology. (and all without making the commit log exude
the odor of entropy incarnate)

> d
> 


Peace

-- 
Pieter