Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2013, 22:28 UTC
Message-ID: <7v61zfselo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <517445E5.3080304@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

> * When I think a batch of patches is ready, I merge them to my master
> and publish my master somewhere.  (Or is it better I publish the feature
> branch and leave it to you to merge directly to your master?)

I think I missed this part, but in the case of git-svn, what we do is the former. The branch Eric makes me pull may be called 'master' in his repository, but it does not contain anything unrelated to git-svn, so from _my_ viewpoint, it is a single "topic to improve git-svn".

But from Eric's point of view, it is an aggregation of different topics from many people on top of my tree, and each topic may tackle its own theme. I think most of the pulls from him so far were single strand of pearls without merges, but if two or more long topics were cooking in his tree, it would have been perfectly reasonable for him to resolve such inter-topic conflicts before telling me to pull the result.

After all, that is what the sub-maintainer of an area is. One who knows the area the best coordinates possibly conflicting changes brought in different topics to the area.

Ths same can go for multimail, or any contrib/ material for that matter.