git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCHv1 0/4] Push options in C Git

From
Jeff King <peff@peff.net>
Date
Jul 1, 2016, 07:09 UTC
Message-ID
<20160701070902.GF5358@sigill.intra.peff.net>
In-Reply-To
<20160630005951.7408-1-sbeller@google.com>
On Wed, Jun 29, 2016 at 05:59:47PM -0700, Stefan Beller wrote:
> Allow a user to pass information along a push to the pre/post-receive hook
> on the remote.
Seems like a reasonable thing to want, and related to:
  http://thread.gmane.org/gmane.comp.version-control.git/285124

which was specifically interested in making "--quiet" and "--force" available, but stopped short of arbitrary data. (It looks like that topic got overlooked, and Dennis never prodded again).

> When using a remote that is more than just a plain Git host (e.g. Gerrit,
> Git{hub/lab}, etc) this may become more obvious: The (server backend specific)
> push options can instruct the server to:
> * open a pull request

I know this is just a "for example", but I don't know if we would ever support opening a pull request directly via push, if only because a good pull request has actual parameters that the user needs to fill out (like the cover letter message).

So you'd probably want some client tool to help the user figure out what to put in the PR, and of course that already exists, because GitHub has an HTTP API that it can talk to. Shoe-horning it into Git doesn't buy much.

I'm not sure if your other examples would be better served by just using an HTTP API or not. I think Gerrit is funny in this regard because it eschews branches entirely. E.g., in a GitHub PR, you push to branch "foo", and then you open a PR using "foo" as the source. But with Gerrit, you push to the magic refs/for/master, and you have no real way to cross-reference that submission later.

Whereas in Dennis's patches, it was about specific information directly related to the act of pushing.

Show 8 quoted lines
> * When pushing to Gerrit you can already attach some of this information by
>   adding a '%' followed by the parameter to the ref, i.e. when interacting with
>   Gerrit it is possible to do things like[1]:
>     
>     git push origin HEAD:refs/for/master%draft%topic=example%cc=jon.doe@example.org
>   
>   This is not appealing to our users as it looks like hacks upon hacks to make
>   it work. It would read better if it was spelled as:
Heh. It _is_ hacks upon hacks, isn't it? ;)
-Peff
Previous: Stefan BellerNext: Stefan Beller
Message 18 of 22 in “[RFC PATCHv1 0/4] Push options in C Git”
  1. Stefan BellerJun 30, 2016
  2. 2/4 receive-pack: implement advertising and receiving push optionsStefan Beller, Jun 30, 2016
  3. Junio C HamanoJul 1, 2016
  4. Stefan BellerJul 1, 2016
  5. 4/4 add a test for push optionsStefan Beller, Jun 30, 2016
  6. 1/4 push options: {pre,post}-receive hook learns about push optionsStefan Beller, Jun 30, 2016
  7. Jeff KingJul 1, 2016
  8. Stefan BellerJul 1, 2016
  9. Jeff KingJul 1, 2016
  10. Junio C HamanoJul 1, 2016
  11. Jeff KingJul 1, 2016
  12. Junio C HamanoJul 1, 2016
  13. Stefan BellerJul 1, 2016
  14. Jeff KingJul 1, 2016
  15. Stefan BellerJul 1, 2016
  16. Stefan BellerJul 1, 2016
  17. 3/4 push: accept push optionsStefan Beller, Jun 30, 2016
  18. Jeff KingJul 1, 2016
  19. Stefan BellerJul 1, 2016
  20. Jeff KingJul 1, 2016
  21. Stefan BellerJul 1, 2016
  22. Jeff KingJul 1, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.