list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Damien Robert <>
To:, Junio C Hamano <>,
	Jeff King <>
Cc: Damien Robert <>
Subject: [RFC PATCH v4 0/2] %(push) and %(push:remoteref) bug fixes
Date: Mon,  6 Apr 2020 19:56:46 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

This fix several bugs in for-each-ref for %(push) and %(push:remoteref), as
explained in the commit messages.

Note that there are still several bugs:
- the memory leak mentioned by Jeff in

- in my patch, to detect if the workflow is triangular, I use:

static int is_workflow_triangular(struct branch *branch)
	struct remote *fetch_remote = remote_get(remote_for_branch(branch, NULL));
	struct remote *push_remote = remote_get(pushremote_for_branch(branch, NULL));
	return (fetch_remote && push_remote && fetch_remote != push_remote);

But remote_get will always fallback to 'origin'. So this means that if we
set up a pushRemote="foobar" and no 'remote', the workflow is detected as

Whereas in `git push`, this workflow will not be detected as triangular.

=> So I can check that by looking at *explicit, but I actually have a
question about what constitutes a triangular workflow, hence the RFC.

Furthermore, the upstream (and simple in non triangular workflow) case of
%(push) and (push:remoteref) are essentially via `branch_get_upstream`, which
is also used for %(upstream):

	branch && branch->merge && branch->merge[0] &&

but `git push` does different checks:

	if (!branch->merge_nr || !branch->merge || !branch->remote_name)
		die(_("The current branch %s has no upstream branch.\n"...
	if (branch->merge_nr != 1)
		die(_("The current branch %s has multiple upstream branches, "
		    "refusing to push."), branch->name);

in particular git push fails if merge_nr !=1 or if branch has no remote,
whereas %(push) will still indicates a push branch (assuming I fix

So I'll need to add a `branch_get_push` with these checks instead.

So I first send this patch as an RFC, and I'll see how to proceed
afterwards to handle these remaining corner cases.
Luckily, having a pushRemote but no remote, or several merge in the branch
config are probably not too common.

=> So one question I have first is about the case when we do have a
branch.pushRemote but not a branch.remote.
Should this still be considered a triangular workflow?

According to git-push, no:

	static int is_workflow_triangular(struct remote *remote)
		struct remote *fetch_remote = remote_get(NULL);
		return (fetch_remote && fetch_remote != remote);

but I would argue that we should.

This would change nothing for push.default=upstream, since currently we
check that `branch` has a remote_name in `setup_push_upstream` so it fails
anyway even if the workflow is not explicitly triangular, but this would
make push.default=simple behave as current, exactly as when branch.remote
is different from branch.pushRemote (and I would argue that no
branch.remote is a particular case of this situation).

PS: the first patch has no tests because I add them in the second patch, it
is more convenient to add them at once and test both patches.

PPS: v4 and v5 are intermediate versions I made but did not send to the ML.

Damien Robert (2):
  remote.c: fix %(push) for triangular workflows
  remote.c: fix handling of %(push:remoteref)

 remote.c                | 139 ++++++++++++++++++++++++++++++----------
 t/ |  81 +++++++++++++++++++++--
 2 files changed, 180 insertions(+), 40 deletions(-)

Patched on top of v2.26.0-106-g9fadedd637 (git version 2.26.0)

  parent reply	other threads:[~2020-04-06 17:57 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28 17:24 [PATCH 1/1] remote.c: fix handling of push:remote_ref Damien Robert
2020-02-28 18:23 ` Jeff King
2020-03-01 22:05   ` Damien Robert
2020-03-02 13:32     ` Jeff King
2020-03-03 16:12       ` [PATCH v2 0/2] Damien Robert
2020-03-03 16:12         ` [PATCH v2 1/2] remote: drop "explicit" parameter from remote_ref_for_branch() Damien Robert
2020-03-03 17:51           ` Junio C Hamano
2020-03-03 21:11             ` Jeff King
2020-03-03 22:22               ` Junio C Hamano
2020-03-03 16:12         ` [PATCH v2 2/2] remote.c: fix handling of %(push:remoteref) Damien Robert
2020-03-03 16:29           ` Damien Robert
2020-03-03 18:29             ` Junio C Hamano
2020-03-03 18:21           ` Junio C Hamano
2020-03-03 22:24             ` Damien Robert
2020-03-03 22:48               ` Junio C Hamano
2020-03-12 16:45           ` [PATCH v3 1/1] " Damien Robert
2020-03-25 22:16             ` Damien Robert
2020-03-27 22:08               ` Junio C Hamano
2020-03-28 22:25                 ` Damien Robert
2020-03-28 13:15             ` Jeff King
2020-03-28 13:31               ` Jeff King
2020-04-16 15:12                 ` Damien Robert
2020-04-06 16:04               ` Damien Robert
2020-04-06 21:46                 ` Jeff King
2020-04-06 17:56             ` Damien Robert [this message]
2020-04-06 17:56               ` [PATCH v6 1/2] remote.c: fix %(push) for triangular workflows Damien Robert
2020-04-06 17:56               ` [PATCH v6 2/2] remote.c: fix handling of %(push:remoteref) Damien Robert
2020-04-16 15:03             ` [PATCH v8 1/1] " Damien Robert
2020-04-16 15:21               ` Damien Robert
2020-09-03 22:01                 ` Junio C Hamano
2020-09-11 21:43                   ` Damien Robert
2020-09-14 22:21                     ` Junio C Hamano
2020-03-03 16:16       ` [PATCH 1/1] remote.c: fix handling of push:remote_ref Damien Robert
2020-03-02 13:48     ` Jeff King
2020-03-03 16:25       ` Damien Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH v4 0/2] %(push) and %(push:remoteref) bug fixes' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).