git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] remote: rename also remotes in the branch.<name>.pushRemote config
Date: Thu, 16 Jan 2020 15:14:11 -0800	[thread overview]
Message-ID: <xmqq7e1rf0zg.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <5a8791ef1e262d2078a4ca26b87bfbd777bd4432.1579209398.git.bert.wesarg@googlemail.com> (Bert Wesarg's message of "Thu, 16 Jan 2020 22:25:26 +0100")

Bert Wesarg <bert.wesarg@googlemail.com> writes:

> Subject: Re: [PATCH] remote: rename also remotes in the branch.<name>.pushRemote config
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>

This is way under-explained.

It is not even clear what "also" in "remote: rename also remotes..."
refers to.  It hints that something that is not "remotes" is
renamed, but the readers do not know what it is.  It is not clear
when that said renaming is done, either.  

Is it supposed to be a bugfix?  If so, readers would need the issue
being addressed described, perhaps like so:

	When X is done, Y is renamed, but at the same time Z should
	also be renamed, but it is not.

> ---
> Cc: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  builtin/remote.c  | 16 ++++++++++++++--
>  t/t5505-remote.sh |  4 +++-
>  2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/remote.c b/builtin/remote.c
> index 96bbe828fe..ddceba868a 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -246,7 +246,7 @@ static int add(int argc, const char **argv)
>  }
>  
>  struct branch_info {
> -	char *remote_name;
> +	char *remote_name, *push_remote_name;
>  	struct string_list merge;
>  	enum {
>  		NO_REBASE, NORMAL_REBASE, INTERACTIVE_REBASE, REBASE_MERGES
> @@ -269,13 +269,16 @@ static int config_read_branches(const char *key, const char *value, void *cb)
>  		char *name;
>  		struct string_list_item *item;
>  		struct branch_info *info;
> -		enum { REMOTE, MERGE, REBASE } type;
> +		enum { REMOTE, PUSH_REMOTE, MERGE, REBASE } type;

Is there a reason why this new one has to come between REMOTE and
MERGE?  Otherwise, the usual convention is either to add
alphabetically (if the list is sorted alphabetically from the
beginning) or add to the end (otherwise).

>  		size_t key_len;
>  
>  		key += 7;
>  		if (strip_suffix(key, ".remote", &key_len)) {
>  			name = xmemdupz(key, key_len);
>  			type = REMOTE;
> +		} else if (strip_suffix(key, ".pushremote", &key_len)) {
> +			name = xmemdupz(key, key_len);
> +			type = PUSH_REMOTE;
>  		} else if (strip_suffix(key, ".merge", &key_len)) {
>  			name = xmemdupz(key, key_len);
>  			type = MERGE;
> @@ -294,6 +297,10 @@ static int config_read_branches(const char *key, const char *value, void *cb)
>  			if (info->remote_name)
>  				warning(_("more than one %s"), orig_key);
>  			info->remote_name = xstrdup(value);
> +		} else if (type == PUSH_REMOTE) {
> +			if (info->push_remote_name)
> +				warning(_("more than one %s"), orig_key);
> +			info->push_remote_name = xstrdup(value);
>  		} else if (type == MERGE) {
>  			char *space = strchr(value, ' ');
>  			value = abbrev_branch(value);
> @@ -680,6 +687,11 @@ static int mv(int argc, const char **argv)
>  			strbuf_addf(&buf, "branch.%s.remote", item->string);
>  			git_config_set(buf.buf, rename.new_name);
>  		}
> +		if (info->push_remote_name && !strcmp(info->push_remote_name, rename.old_name)) {
> +			strbuf_reset(&buf);
> +			strbuf_addf(&buf, "branch.%s.pushremote", item->string);
> +			git_config_set(buf.buf, rename.new_name);
> +		}
>  	}
>  
>  	if (!refspec_updated)
> diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
> index 883b32efa0..59a1681636 100755
> --- a/t/t5505-remote.sh
> +++ b/t/t5505-remote.sh
> @@ -737,12 +737,14 @@ test_expect_success 'rename a remote' '
>  	git clone one four &&
>  	(
>  		cd four &&
> +		git config branch.master.pushRemote origin &&
>  		git remote rename origin upstream &&
>  		test -z "$(git for-each-ref refs/remotes/origin)" &&
>  		test "$(git symbolic-ref refs/remotes/upstream/HEAD)" = "refs/remotes/upstream/master" &&
>  		test "$(git rev-parse upstream/master)" = "$(git rev-parse master)" &&
>  		test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/remotes/upstream/*" &&
> -		test "$(git config branch.master.remote)" = "upstream"
> +		test "$(git config branch.master.remote)" = "upstream" &&
> +		test "$(git config branch.master.pushRemote)" = "upstream"
>  	)
>  '

OK, so the issue the patch wants to address is

	git remote rename X Y

ought to rename branch.X.Z (for any value of Z) to branch.Y.Z but it
forgot to do so for Z==pushRemote?

If that is the case, I have to wonder if the patch is making the
situation better or even worse.  Shouldn't we be not even caring
what Z is by not having to list these specific keys?  I dunno.


  reply	other threads:[~2020-01-16 23:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 21:25 [PATCH] remote: rename also remotes in the branch.<name>.pushRemote config Bert Wesarg
2020-01-16 23:14 ` Junio C Hamano [this message]
2020-01-17  9:33   ` [PATCH v2] remote rename: rename branch.<name>.pushRemote config values too Bert Wesarg
2020-01-17 11:50     ` Johannes Schindelin
2020-01-17 12:37       ` Bert Wesarg
2020-01-17 13:30         ` Johannes Schindelin
2020-01-17 14:40           ` Bert Wesarg
2020-01-20 11:25             ` Johannes Schindelin
2020-01-20 13:14               ` Bert Wesarg
2020-01-20 13:51                 ` Johannes Schindelin
2020-01-17 18:48     ` Junio C Hamano
2020-01-17 20:20       ` Bert Wesarg
2020-01-17 21:24         ` Junio C Hamano
2020-01-21  9:24     ` [PATCH 0/7] remote rename: improve handling of configuration values Bert Wesarg
2020-01-21  9:24       ` [PATCH 1/7] pull --rebase/remote rename: document and honor single-letter abbreviations rebase types Bert Wesarg
2020-01-21 23:26         ` Junio C Hamano
2020-01-22  7:34           ` Bert Wesarg
2020-01-22 19:43             ` Junio C Hamano
2020-01-21  9:24       ` [PATCH 2/7] remote: clean-up by returning early to avoid one indentation Bert Wesarg
2020-01-23 23:02         ` Junio C Hamano
2020-01-21  9:24       ` [PATCH 3/7] remote: clean-up config callback Bert Wesarg
2020-01-21  9:24       ` [PATCH v3 4/7] remote rename: rename branch.<name>.pushRemote config values too Bert Wesarg
2020-01-21  9:24       ` [PATCH 5/7] [RFC] config: make `scope_name` global as `config_scope_name` Bert Wesarg
2020-01-22  0:12         ` Matt Rogers
2020-01-22  7:37           ` Bert Wesarg
2020-01-23  1:30             ` Matt Rogers
2020-01-21  9:24       ` [PATCH 6/7] config: provide access to the current line number Bert Wesarg
2020-01-21  9:24       ` [PATCH 7/7] remote rename: gently handle remote.pushDefault config Bert Wesarg
2020-01-23 23:03         ` Junio C Hamano
2020-01-24  8:49           ` Bert Wesarg
2020-01-22 15:26       ` [PATCH 0/7] remote rename: improve handling of configuration values Bert Wesarg
2020-01-17  9:49   ` [PATCH] remote: rename also remotes in the branch.<name>.pushRemote config Johannes Schindelin
2020-01-17  9:45 ` Johannes Schindelin

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

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

  git send-email \
    --in-reply-to=xmqq7e1rf0zg.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=bert.wesarg@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    /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.
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 NNTP newsgroup(s).