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

Re: [PATCH v3 1/1] remote.c: fix handling of %(push:remoteref)

From
Jeff King <peff@peff.net>
Date
Apr 6, 2020, 21:46 UTC
Message-ID
<20200406214607.GA1251506@coredump.intra.peff.net>
In-Reply-To
<20200406160439.gg5uu6kepnyxpvuc@feanor>
On Mon, Apr 06, 2020 at 06:04:39PM +0200, Damien Robert wrote:
Show 9 quoted lines
> Heres what happen with such a triangular workflow when we do a `git push`:
> - with push.default=simple, we have
> 	case PUSH_DEFAULT_SIMPLE:
> 		if (triangular)
> 			setup_push_current(remote, branch);
> 		else
> 			setup_push_upstream(remote, branch, triangular, 1);
> 		break;
>   so the current branch is always pushed.

Yeah, otherwise every push to a remote other than origin would require a refspec. I think with respect to for-each-ref, this "triangular" case would only kick in if you define remote.pushDefault (since you can't specify a remote on the command-line).

Though hmm. I guess maybe it could kick in if the upstream of the branch is on a non-default remote? For push, that would work because remote_get() will look at the current branch. But of course in for-each-ref, we're asking speculatively about other branches.

So I think if we want to support this triangular logic in for-each-ref, we need to have a more careful definition than what's in push.c's is_workflow_triangular(). I.e., it would probably make sense to consider it from the position of "if we were on this branch, what would it push".

And ditto for @{push}, I guess.
Show 11 quoted lines
> - with push.default=upstream, we have
> 	case PUSH_DEFAULT_UPSTREAM:
> 		setup_push_upstream(remote, branch, triangular, 0);
> 		break;
>   which then gives
>   	if (triangular)
> 		die(_("You are pushing to remote '%s', which is not the upstream of\n"
> 		      "your current branch '%s', without telling me what to push\n"
> 		      "to update which remote branch."),
> 
> By the way this matches what the documentation says.

Yeah. I think in the triangular case (at least as defined in push.c) we'd always be pushing to the non-upstream, so this die() makes sense.

In for-each-ref, I guess we'd hit this case with remote.pushDefault again. Without that, we'd always be pushing to the upstream anyway.

Show 12 quoted lines
> However here is the result of
> git -c push.default=$value for-each-ref --format="%(push:remotename),%(push:remoteref),%(push)" refs/heads/master
> for $value=
> - simple: to,,
> - upstream: to,refs/heads/other,refs/remotes/from/other
> 
> Note that without my patch the %(push:remoteref) values would always be empty,
> but my patch does not touch %(push).
> 
> So in both branch_get_push_1 and branch_get_push_remoteref I should first
> detect if we have a triangular workflow, and update the logic of the code
> accordingly.

Yes, I agree this could be improved. I'm OK leaving that as a separate fix to your current remoteref work, though.

-Peff
Previous: Damien RobertNext: Damien Robert
Message 24 of 32 in “remote.c: fix handling of push:remote_ref”
  1. 1/1 remote.c: fix handling of push:remote_refDamien Robert, Feb 28, 2020
  2. Jeff KingFeb 28, 2020
  3. Damien RobertMar 1, 2020
  4. Jeff KingMar 2, 2020
  5. 0/2 Damien Robert, Mar 3, 2020
  6. 1/2 remote: drop "explicit" parameter from remote_ref_for_branch()Damien Robert, Mar 3, 2020
  7. Junio C HamanoMar 3, 2020
  8. Jeff KingMar 3, 2020
  9. Junio C HamanoMar 3, 2020
  10. 2/2 remote.c: fix handling of %(push:remoteref)Damien Robert, Mar 3, 2020
  11. Damien RobertMar 3, 2020
  12. Junio C HamanoMar 3, 2020
  13. Junio C HamanoMar 3, 2020
  14. Damien RobertMar 3, 2020
  15. Junio C HamanoMar 3, 2020
  16. 1/1 remote.c: fix handling of %(push:remoteref)Damien Robert, Mar 12, 2020
  17. Damien RobertMar 25, 2020
  18. Junio C HamanoMar 27, 2020
  19. Damien RobertMar 28, 2020
  20. Jeff KingMar 28, 2020
  21. Jeff KingMar 28, 2020
  22. Damien RobertApr 16, 2020
  23. Damien RobertApr 6, 2020
  24. Jeff KingApr 6, 2020
  25. 1/1 remote.c: fix handling of %(push:remoteref)Damien Robert, Apr 16, 2020
  26. Damien RobertApr 16, 2020
  27. Junio C HamanoSep 3, 2020
  28. Damien RobertSep 11, 2020
  29. Junio C HamanoSep 14, 2020
  30. Damien RobertMar 3, 2020
  31. Jeff KingMar 2, 2020
  32. Damien RobertMar 3, 2020

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.