branchs and tags and merges oh my!

David Bremner david at tethera.net
Fri Jul 1 16:47:04 PDT 2011


On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard <keithp at keithp.com> wrote:
> > 2) merge master onto the release branch
> 
> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.

Can you elaborate? Naively it seems like one ends up with the same kind
of spur of history off of the 0.6 tag in both cases.

----.--------------master
    \
     ---- 0.6 ---- bugfix

versus

-----.----------.
      \          \ 
       ---- 0.6--------master
             \
              ----- bugfix

> As an alternative, you probably should have simply put non-release
> patches on a separate 'feature branch' (probably residing in the feature
> author's repository) which would then be merged onto master post-0.6

Yes, that is certainly nice from a git history point of view. On the
other hand the point of separating the roles of feature merger from
release mechanic was to allow Carl more time to work on merging features
into master, and I'm not sure how turning master over to the release
manager helps that.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110701/de55cd63/attachment.pgp>


More information about the notmuch mailing list