git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 3/6] push: change `simple` to accommodate triangular workflows
Date: Wed, 19 Jun 2013 13:00:55 -0700	[thread overview]
Message-ID: <7v38sdzx8o.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1371640304-26019-4-git-send-email-artagnon@gmail.com> (Ramkumar Ramachandra's message of "Wed, 19 Jun 2013 16:41:41 +0530")

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> When remote.pushdefault or branch.<name>.pushremote is set (a triangular
> workflow feature), master@{u} != origin, and push.default is set to
> `upstream` or `simple`:
>
>   $ git push
>   fatal: You are pushing to remote 'origin', which is not the upstream of
>   your current branch 'master', without telling me what to push
>   to update which remote branch.
>
> Unfortunately, in the case of `upstream`, the very name indicates that
> it is only suitable for use in central workflows; let us not even
> attempt to give it a new meaning in triangular workflows, and error out
> as usual.

Sensible.

> However, the `simple` does not have this problem: it is poised to
> be the default for Git 2.0, and we would definitely like it to do
> something sensible in triangular workflows.
>
> Decouple `simple` from `upstream` completely, and change it to mean
> `current` with a safety feature: a `push` and `pull` should not be
> asymmetrical in the special case of central workflows.

Double negation confused my parser.  'push' and 'pull' should be
kept symmetrical in central workflows?

> +* `simple` - a safer version of `current`; push the current branch to
> +  update a branch with the same name on the receiving end, with a
> +  safety feature: in central workflows, error out if
> +  branch.$branch.merge is set and not equal to $branch,

If branch.$branch.merge is _not_ set, what happens in the current
code, and what should happen?

> + to make sure
> +  that a `push` and `push` are never asymmetrical.  It will become the
> +  default in Git 2.0.

Ditto.

>  * `matching` - push all branches having the same name on both ends
>    (essentially ignoring all newly created local branches).
> diff --git a/builtin/push.c b/builtin/push.c
> index 2d84d10..d8d27d9 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -120,6 +120,25 @@ static const char message_detached_head_die[] =
>  	   "\n"
>  	   "    git push %s HEAD:<name-of-remote-branch>\n");
>  
> +static void setup_push_simple(struct remote *remote)
> +{
> +	struct branch *branch = branch_get(NULL);
> +	if (!branch)
> +		die(_(message_detached_head_die), remote->name);

OK.

> +	if (!branch->merge_nr || !branch->merge || !branch->remote_name)
> +		/* No upstream configured */
> +		goto end;

Without any configuration the current branch is pushed out, which
loosens the safety we implemented in the current 'safer upstream'.

I am not convinced this is a good change.  I am not convinced this is
a bad change, either, yet, but this loosening smells bad.

> diff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh
> index 69ce6bf..e54dd02 100755
> --- a/t/t5528-push-default.sh
> +++ b/t/t5528-push-default.sh
> @@ -85,7 +85,7 @@ test_expect_success 'push from/to new branch with current creates remote branch'
>  test_expect_success 'push to existing branch, with no upstream configured' '
>  	test_config branch.master.remote repo1 &&
>  	git checkout master &&
> -	test_push_failure simple &&
> +	test_push_success simple master &&
>  	test_push_failure upstream
>  '

Likewise.

  reply	other threads:[~2013-06-19 20:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19 11:11 [PATCH 0/6] push.default in the triangular world Ramkumar Ramachandra
2013-06-19 11:11 ` [PATCH 1/6] t/t5528-push-default: remove redundant test_config lines Ramkumar Ramachandra
2013-06-19 19:26   ` Junio C Hamano
2013-06-19 11:11 ` [PATCH 2/6] config doc: rewrite push.default section Ramkumar Ramachandra
2013-06-19 19:55   ` Junio C Hamano
2013-06-20  3:27     ` Junio C Hamano
2013-06-20  7:35       ` Johan Herland
2013-06-19 11:11 ` [PATCH 3/6] push: change `simple` to accommodate triangular workflows Ramkumar Ramachandra
2013-06-19 20:00   ` Junio C Hamano [this message]
2013-06-20  2:57     ` Junio C Hamano
2013-06-20 10:09       ` Ramkumar Ramachandra
2013-06-20 19:23         ` Junio C Hamano
2013-06-20 20:49           ` Philip Oakley
2013-06-20 21:03             ` Junio C Hamano
2013-06-20 21:22           ` Ramkumar Ramachandra
2013-06-20 21:56             ` Junio C Hamano
2013-06-20 22:05               ` Junio C Hamano
2013-06-20 21:41       ` Junio C Hamano
2013-06-19 11:11 ` [PATCH 4/6] push: remove dead code in setup_push_upstream() Ramkumar Ramachandra
2013-06-19 20:01   ` Junio C Hamano
2013-06-19 11:11 ` [PATCH 5/6] t/t5528-push-default: generalize test_push_* Ramkumar Ramachandra
2013-06-19 21:56   ` Junio C Hamano
2013-06-19 11:11 ` [PATCH 6/6] t/t5528-push-default: test pushdefault workflows Ramkumar Ramachandra
2013-06-19 22:17   ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2013-06-24  4:33 [PATCH 0/6] Reroll of rr/triangular-push-fix Junio C Hamano
2013-06-24  4:33 ` [PATCH 3/6] push: change `simple` to accommodate triangular workflows Junio C Hamano
2013-06-24  6:58   ` Johan Herland
2013-06-24  7:43     ` Junio C Hamano
2013-06-24  7:46     ` Ramkumar Ramachandra
2013-06-24  8:48       ` Johan Herland
2013-06-24 14:13         ` Ramkumar Ramachandra
2013-06-24  7:59     ` Junio C Hamano
2013-06-24  8:48       ` Johan Herland

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=7v38sdzx8o.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).