Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Brian Harring <ferringb@gmail.com>]

On Mon, Jun 04, 2012 at 03:49:31AM +0000, Kent Fredric wrote:
> On 3 June 2012 09:46, Robin H. Johnson <robbat2@gentoo.org> wrote:
>  If there are enough "Alice" developers, is it a possibility that Bob
> > will never have a chance to get his commit in?
> >
> > All this requires, is that in the time it takes Bob to do 'git pull',
> > Alice manages to do 'git push' again.
> >
> > Alice can thus deprive Bob of a fair chance to get his commit in.
> > Bob becomes an unhappy developer and gives up.
> 
> There's an easier solution here:
> 
> Bob pushes to a branch or to a public repo ( ie: github ) , and then
> contacts Alice ( or somebody else ) who pulls their changes into the
> tree on their behalf.
> 
> Its not "ideal" but better than nothing. And certainly better than
> being stuck on SVN where this case is virtually guaranteed and with no
> viable workarounds when it is encountered.


Kent, you did read Robin's email fully before commenting, right? ;)

You just proposed 'merge lieutenants', which Robin already covered in 
the originating email of this thread:
http://archives.gentoo.org/gentoo-dev/msg_f478e9cbb14feb01ad0771c5d24222c4.xml 


For the record, I'm against any form of merge lieutenant reliant on 
someone pulling shit in; automated (QA of some form) I'd be fine w/, 
although that's not simple machinery to slap into the proposals.

While I do grok the potential issue of someone being a hog 
(specifically via blasting commit by commit rather than building up 
work locally, then pushing it in chunks), frankly... I'm not that 
concerned about it, and would rather deal w/ it if/when it occurs.  
The nature of our commits for the most part are standalone from 
others- that's not true of the kernel/mozilla, thus why I don't think 
their issues are necessarily ours.

~harring