On 10 July 2015 at 15:38, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > I realise I'm coming to this conversation late, but: > > I have some experience of writing a stunt git push receiver. I would > be willing to write another. > > The rough shape would be something like: > > * Instead of doing git-request-pull, submitter does git push to some > special URL (perhaps an ssh git url, or perhaps a git:// one). > > * Software behind the url stores the incoming branch in an invented > branch name in the master repo, so that `git fetch' can see it. > > * Invented branch name (or url or something) is shown to pushing > user, as a reference. > > * Automatic email is sent to someone saying "someone pushed this for > review" with branch name. > > AFAICT this is more or less like git-request-pull except that: > > - The objects are stored on the reviewers'/maintainers' system (so > the submitter does not need to operate or use another git server) > > - The submitter interacts by doing `git push', not by sending an > email. > > - The maintainers' can see the branches in git on their server. >
What you have described here is github pull requests =) they use refs/pull/# namespace though, so one needs to tweak fetch config to get them all. You similarly described gerrit here, one pushes to a magic refs/for/master to create a merge proposal from here into refs/for/master. However gerrit does something fance and splits each commit into a separate merge proposal essentially which are all stacked. (git review is just fancy wrappers around git push HEAD:refs/for/something). Above two do generate stand-alone emails. Something more lightweight however would be hooks for gitolite. One can already enable pushes that create branches there, and then further restrict things. One would need a hook to generate email notifications about new pushes. But there is a lightweight gating mechanism in place already, e.g. by pushing refs to votes/$voter/$branch one can +1 things. https://github.com/sitaramc/gitolite/blob/master/src/VREF/VOTES I have not looked into implementation details but I believe gitlab & bitbucket expose merge proposals in a similar fashion. The problem with all of these they are still centralised. gerrit is slightly better, as it stores all the review details as git notes, and thus one can migrate them away without any loss of information. A distributed code review would be better, where one pushes and/or uploads git bundle. (either to one's own, or to the public one for a given project, or generic one) and then that is exposed as e.g. shallow branches. Having a bridge for review comments as e.g. git notes would be a win. There is also a bridge between git send-email generated emails and github pull requests. A project somewhere on github. By default it generates branches, and send an email back to e.g. mailing list "import as branch $foo, click here to create a pull request on github, if you wish." > (It may be that there is already some software that does this. If so > I'm not aware of it.) > There are multiple, some of them are even free (gitlab, gerrit, gitolite with hand written hooks) but all of them have it's own semantics/workflows which may be sub-optimal. > Tollef, would that be the kind of thing you would like to use ? > If so I would be happy to discuss a more detailed specification with > you and then implement it. > I want mentors.debian.net to accept git am formated patch / or a debdiff against any packaging =) that would cover 90% of my review needs in debian. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhluid-jurynyovbvype+4x_gfjqk5ntfncchy5usbyfn...@mail.gmail.com