[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’



On 2015-07-10 16:55:23 +0100 (+0100), Ian Jackson wrote:
[...]
> I was aware that gerrit has something a bit like this.
> 
> But this:
> 
> >   https://github.com/openstack-infra/git-review
> >   https://packages.debian.org/git-review
> 
> is a submission tool.  It doesn't do the server side.
> 
> I don't think you can use it with a simple git server (and you
> wouldn't want to grant wide access to push to random branches on your
> git server).
[...]

Right, it depends on the fact that Gerrit lets arbitrary users push
into a "refs/for/refs/*" prefix, and Gerrit provides project admins
the ability to set very fine-grained ACLs around refname patterns.
The merging back into your real branches happens based on actions
within Gerrit itself (either via WebUI or API calls).

Simulating Gerrit's behaviors in this regard would probably not
satisfy the desire for a "replacement for pull requests" however
since Gerrit assumes a LKML-esque "rebase your patch until you get
it right" approach rather than the "keep stacking more fixes onto
your broken patch" method that Github users have come to expect.
Gerrit uses git parentage between proposed commits more like a
topic branch of dependent changes, which people who have mainly only
used Github tend to find very bizzare/confusing/annoying.

Also this Gerrit-oriented workflow assumption is pretty heavily
baked into git-review, and as one of its primary maintainers I don't
think I would be interested in patches which attempt to turn it into
a general client for various sorts of git servers (though I'm open
to being convinced otherwise).
-- 
Jeremy Stanley

Attachment: signature.asc
Description: Digital signature


Reply to: