git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Glen Choo <chooglen@google.com>
To: Junio C Hamano <gitster@pobox.com>,
	Tao Klerks via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Tao Klerks" <tao@klerks.biz>
Subject: Re: [PATCH v3] tracking branches: add advice to ambiguous refspec error
Date: Mon, 28 Mar 2022 10:12:07 -0700	[thread overview]
Message-ID: <kl6l7d8et314.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <xmqqwnge2ghe.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

>> diff --git a/branch.c b/branch.c
>> index 6b31df539a5..5c28d432103 100644
>> --- a/branch.c
>> +++ b/branch.c
>> @@ -18,9 +18,15 @@ struct tracking {
>>  	int matches;
>>  };
>>  
>> +struct find_tracked_branch_cb {
>> +	struct tracking *tracking;
>> +	struct strbuf remotes_advice;
>> +};
>> +
>>  static int find_tracked_branch(struct remote *remote, void *priv)
>>  {
>> -	struct tracking *tracking = priv;
>> +	struct find_tracked_branch_cb *ftb = priv;
>> +	struct tracking *tracking = ftb->tracking;
>>  
>>  	if (!remote_find_tracking(remote, &tracking->spec)) {
>>  		if (++tracking->matches == 1) {
>>  			string_list_append(tracking->srcs, tracking->spec.src);
>>  			tracking->remote = remote->name;
>>  		} else {
>>  			free(tracking->spec.src);
>>  			string_list_clear(tracking->srcs, 0);
>>  		}
>> +		/*
>> +		 * TRANSLATORS: This is a line listing a remote with duplicate
>> +		 * refspecs, to be later included in advice message
>> +		 * ambiguousFetchRefspec. For RTL languages you'll probably want
>> +		 * to swap the "%s" and leading "  " space around.
>> +		 */
>> +		strbuf_addf(&ftb->remotes_advice, _("  %s\n"), remote->name);
>>  		tracking->spec.src = NULL;
>>  	}
>
> This is wasteful.  remotes_advice does not have to be filled when we
> are not going to give advice, i.e. there is only one matching remote
> and no second or subsequent ones, which should be the majority case.
> And we should not make majority of users who do not make a mistake
> that needs the advice message pay the cost of giving advice to those
> who screw up, if we can avoid it.
>
> Instead, only when we are looking at the second one, we can stuff
> tracking->remote (i.e. the first one) to remotes_advice, and then
> append remote->name there.  Perhaps we can do it like so?
>
> 	struct strbuf *names = &ftb->remotes_advice;
> 	const char *namefmt = N_("  %s\n");
>
> 	switch (++tracking->matches) {
> 	case 1:
> 		string_list_append(tracking->srcs, tracking->spec.src);
> 		tracking->remote = remote->name;
> 		break;
> 	case 2:
> 		strbuf_addf(names, _(namefmt), tracking->remote);
> 		/* fall through */
> 	default:
> 		strbuf_addf(names, _(namefmt), remote->name);
>                 free(tracking->spec.src);
>                 string_list_clear(tracking->srcs, 0);
>                 break;
> 	}
> 	tracking->spec.src = NULL;
>
> For a bonus point, remotes_advice member can be left empty without
> paying the cost to strbuf_addf() when the advice configuration says
> we are not going to show the message.
>
> Thanks.

Hm, what do you think of an alternate approach of storing of the
matching remotes in a string_list, something like:

  struct find_tracked_branch_cb {
  	struct tracking *tracking;
  	struct string_list matching_remotes;
  };
  
  static int find_tracked_branch(struct remote *remote, void *priv)
  {
  	struct tracking *tracking = priv;
  	struct find_tracked_branch_cb *ftb = priv;
  	struct tracking *tracking = ftb->tracking;
  
  	if (!remote_find_tracking(remote, &tracking->spec)) {
  		if (++tracking->matches == 1) {
  			string_list_append(tracking->srcs, tracking->spec.src);
  			tracking->remote = remote->name;
  		} else {
  			free(tracking->spec.src);
  			string_list_clear(tracking->srcs, 0);
  		}
  		string_list_append(&ftb->matching_remotes, remote->name);
  		tracking->spec.src = NULL;
  	}

then construct the advice message in setup_tracking()? To my untrained
eye, "case 2" requires a bit of extra work to understand.

  reply	other threads:[~2022-03-28 17:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 10:23 [PATCH] tracking branches: add advice to ambiguous refspec error Tao Klerks via GitGitGadget
2022-03-21 14:11 ` Ævar Arnfjörð Bjarmason
2022-03-22  9:09   ` Tao Klerks
2022-03-22  9:18 ` [PATCH v2] RFC: " Tao Klerks via GitGitGadget
2022-03-22 10:04   ` Ævar Arnfjörð Bjarmason
2022-03-28  6:51   ` [PATCH v3] " Tao Klerks via GitGitGadget
2022-03-28 16:23     ` Junio C Hamano
2022-03-28 17:12       ` Glen Choo [this message]
2022-03-28 17:23         ` Junio C Hamano
2022-03-28 18:02           ` Tao Klerks
2022-03-28 18:50             ` Ævar Arnfjörð Bjarmason
2022-03-28 20:32               ` Junio C Hamano
2022-03-28 20:27             ` Junio C Hamano
2022-03-29 11:26               ` Tao Klerks
2022-03-29 11:26     ` [PATCH v4] " Tao Klerks via GitGitGadget
2022-03-29 11:31       ` Tao Klerks
2022-03-29 15:49       ` Junio C Hamano
2022-03-30  4:17         ` Tao Klerks
2022-03-30  7:20       ` [PATCH v5] " Tao Klerks via GitGitGadget
2022-03-30 13:19         ` Ævar Arnfjörð Bjarmason
2022-03-30 14:23           ` Tao Klerks
2022-03-30 15:18             ` Tao Klerks
2022-03-30 17:14               ` Ævar Arnfjörð Bjarmason
2022-03-30 20:37           ` Junio C Hamano
2022-03-30 21:09             ` Ævar Arnfjörð Bjarmason
2022-03-30 22:07               ` Junio C Hamano
2022-03-30 22:51                 ` Ævar Arnfjörð Bjarmason
2022-03-31 16:01         ` [PATCH v6] " Tao Klerks via GitGitGadget
2022-03-31 19:32           ` Junio C Hamano
2022-03-31 23:57             ` Glen Choo
2022-04-01  4:30               ` Tao Klerks
2022-04-01 16:41                 ` Glen Choo
2022-03-31 19:33           ` Junio C Hamano
2022-04-01  6:05           ` [PATCH v7] " Tao Klerks via GitGitGadget
2022-04-01 16:53             ` Glen Choo
2022-04-01 19:57               ` Junio C Hamano

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=kl6l7d8et314.fsf@chooglen-macbookpro.roam.corp.google.com \
    --to=chooglen@google.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=tao@klerks.biz \
    /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).