revised patch for gmime init, with test.
Pieter Praet
pieter at praet.org
Sat Jan 14 00:51:01 PST 2012
On Thu, 12 Jan 2012 23:46:46 -0400, David Bremner <david at tethera.net> wrote:
> On Thu, 12 Jan 2012 18:25:38 +0100, Pieter Praet <pieter at praet.org> wrote:
> > On Sat, 31 Dec 2011 23:22:46 -0400, David Bremner <david at 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. [...]
This *can* get rather messy when interlacing the 'master'/'maint' merges
with non-rebased changesets pulled from other repos (most often aren't
rebased in advance since they've already been published), which is a
common occurence in the magit [1] repo.
But take Org-mode [2] for example (which is an *extremely* active project),
where non-rebased changesets are rare(ish), and where the 'maint' branch
is constantly being merged back into 'master', resulting in a very clean
ladder-like commit log, eg. :
--*----*----*----*----*----*---*----*---*---*--- master
\ / / \
*-------*-------*-------------*-----------*--- maint
0.11 bugfix NEWS bugfix 0.12~rc1
> [...] [1] would have also been prevented by making the patch against
> the right branch.
>
True, but if we can obviate the need to check if we're on the right
branch altogether, without causing any unwanted side-effects, wouldn't
it be counterproductive not to?
Peace
--
Pieter
[1] git://github.com/magit/magit.git
[2] git://orgmode.org/org-mode.git
More information about the notmuch
mailing list