Andrew, what are your thoughts about this? What can be found there and
how can we use it?
/Mads
On 07/17/2015 01:59 PM, Andrew Shadura wrote:
It turns out the way I tried to forward this email didn't work well.
---------- Forwarded message ----------
From: Simon McVittie <[email protected]>
Date: 17 July 2015 at 01:13
Subject: Re: GitHub “pull request ” is proprietary, incom patible with
Git ‘requ est-pull ’
To: [email protected]
On 16/07/15 18:14, Ian Jackson wrote:
Can you point me at the server code, or configuration that handled
your push ?
Documentation: https://ikiwiki.info/tips/untrusted_git_push/
Implementation (it's a pre-receive hook):
http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki/Receive.pm;h=5908e09f953ad09cb576cae6c956230be497d6df;hb=HEAD
http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki/Plugin/git.pm;h=4d48388a04fdc2e9c3d6ea7c71b40d3ba3ccd88c;hb=HEAD#l894
That commit is on HEAD. But the request was for the pushed commits to
land somewhere else.
ikiwiki doesn't currently do what you request, because all it needs for
its current functionality is the ability to accept or decline pushes to
branches; but AIUI the same mechanisms in a pre-receive hook can be used
to divert them elsewhere.
I think this is also how the ability to "git push" to a Gerrit instance
works: you do something like "git push gerrit bug123:refs/for/master",
and gerrit interprets that as a pull request targeting master, and makes
the commits available for review in its web UI.
The request included the notion that the repo or branch owner would
get told somehow about the push.
ikiwiki's pre-receive hook doesn't *directly* do that, although it could
(it has the opportunity to do whatever is desired with the git log/diff
that it's receiving).
S
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general