On Mon, Jun 04, 2012 at 03:49:31AM +0000, Kent Fredric wrote:
> On 3 June 2012 09:46, Robin H. Johnson <email@example.com> 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:
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.