git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Schumacher <timschumi@gmx.de>
To: "Jeff King" <peff@peff.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, pclouds@gmail.com
Subject: Re: [PATCH v3] Allow aliases that include other aliases
Date: Thu, 6 Sep 2018 21:05:50 +0200	[thread overview]
Message-ID: <dea58ad8-4e2a-955a-8dc6-b93e9592398c@gmx.de> (raw)
In-Reply-To: <20180906145708.GA1209@sigill.intra.peff.net>

On 06.09.18 16:57, Jeff King wrote:
> On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
>> If we don't have some test for these sort of aliasing loops that fails
>> now, we really should add that in a 1/2 and fix it in this patch in 2/2.
> 
> Yes, I'd agree that this is worth adding a test (especially if the
> output routines get more complex).

I'll try to come up with a few tests (or one at this point, as we only have
a solution for internal aliases so far) and put them as 1/2. However, I don't know
what file I should put those tests into. t0001-init and t1300-config both seem
to test aliases, but I'm unsure if the new tests should go into one of those
files or a completely new one that is dedicated to aliases.

> 
>> That makes sense from an implementaion perspective, i.e. we lookup "bar"
>> twice. But let's do better. If I have aliase like:
>>
>>      a = b
>>      b = c
>>      c = d
>>      d = e
>>      e = c
>>
>> It should be telling me that my "e" expansion looped back to the "c = d"
>> expansion. Here's a patch to implement that, feel free to either squash
>> it in with my Signed-Off-By, or tacked onto a v4 version of this,
>> whichever you think makes sense:
> 
> I don't have a strong opinion on whether this is worth it, but I think
> your implementation could be a little simpler:
> 
>> diff --git a/git.c b/git.c
>> index 64f5fbd572..38f1033e52 100644
>> --- a/git.c
>> +++ b/git.c
>> @@ -692,8 +692,64 @@ static int run_argv(int *argcp, const char ***argv)
>>   		/* .. then try the external ones */
>>   		execv_dashed_external(*argv);
>>
>> -		if (string_list_has_string(&cmd_list, *argv[0]))
>> -			die(_("loop alias: %s is called twice"), *argv[0]);
>> +		if (string_list_has_string(&cmd_list, *argv[0])) {
>> +			struct strbuf sb = STRBUF_INIT;
>> +			int i, seen_at_idx = -1;
>> +
>> +			/*
>> +			 * Find the re-entry point for the alias
>> +			 * loop. TODO: There really should be a
>> +			 * "return the index of the first matching"
>> +			 * helper in string-list.c.
>> +			 */
>> +			for (i = 0; i < cmd_list.nr; i++) {
>> +				if (!strcmp(*argv[0], cmd_list.items[i].string))
>> +					seen_at_idx = i;
>> +			}
>> +			assert(seen_at_idx != -1);
> 
> The string-list code doesn't generally deal in indices. You can use
> string_list_find_insert_index(), but its return value is a little funky
> for the existing case. You can also just do:
> 
>    struct string_list_item *seen;
>    ...
>    seen = string_list_lookup(&cmd_list, *argv[0]);
>    if (seen) {
> 	/* we have a loop */
> 	int idx = seen - cmd_list.items;
> 
> That's a little intimate with the string-list implementation as an array
> of string_list, but it's already pretty standard to walk over and
> dereference that list (including in your patch). But also see below.
> 
> Side note: there's actually a bigger problem with the original patch:
> the string list is unsorted (because it uses string_list_append(), and
> which is why your linear walk works here). But string_list_has_string()
> assumes it is sorted.  So I think we'd actually want to use
> unsorted_string_list_has_string() or unsorted_string_list_lookup().

I'll update v4 to use use unsorted_string_list_has_string().
> 
>> +			for (i = 1; i < cmd_list.nr; i++) {
>> +				if (i - 1 == seen_at_idx)
>> +					/*
>> +					 * TRANSLATORS: This is a the
>> +					 * re-enttry point in the list
>> +					 * printed out by the "alias
>> +					 * loop" message below.
>> +					 */
>> +					strbuf_addf(&sb, _("    %d. %s = %s <== The re-entry point in the loop\n"),
>> +						    i,
>> +						    cmd_list.items[i - 1].string,
>> +						    cmd_list.items[i].string);
> 
> This is always going to show the right-hand of the equals as the
> left-hand on the next line. Would it be simpler to just show the list?
> Likewise, the last item in the list is always going to be "where the
> loop started". Do we need to say that?
> 
> E.g., something like:
> 
>    seen = unsorted_string_list_lookup(&cmd_list, *argv[0]);
>    if (seen) {
>            for (i = 0; i < cmd_list.nr; i++) {
> 		struct string_list *item = cmd_list.items[i];
> 
> 		strbuf_addf(&sb, "  %s", item->string);
> 		if (item == seen)
> 			strbuf_add(&sb, " <==");
> 		strbuf_addch(&sb, '\n');
> 	  }
> 	  /* We never added this to the list, but we were about to */
> 	  strbuf_addch("  %s\n", seen->string);
> 	  die(...);
>    }
> 
> I guess it's not that far off of yours. Not using words to describe the
> loop entry and exit points avoids translation, which avoids notes to
> translators, which is most of what makes your patch long. ;)
> 
> -Peff
> 

I'll tinker around with both code snippets, we'll see which one is
more convenient for the user.

Thanks to all of you for the input!

Tim

  parent reply	other threads:[~2018-09-06 19:06 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05  8:54 [RFC PATCH v2] Allow aliases that include other aliases Tim Schumacher
2018-09-05 15:48 ` Duy Nguyen
2018-09-05 19:02   ` Tim Schumacher
2018-09-05 17:12 ` Junio C Hamano
2018-09-05 19:12   ` Tim Schumacher
2018-09-05 17:34 ` Jeff King
2018-09-05 20:02   ` Tim Schumacher
2018-09-06 13:38     ` Ævar Arnfjörð Bjarmason
2018-09-06 14:17     ` Ævar Arnfjörð Bjarmason
2018-10-18 22:57       ` [PATCH] alias: detect loops in mixed execution mode Ævar Arnfjörð Bjarmason
2018-10-19  8:28         ` Ævar Arnfjörð Bjarmason
2018-10-19 22:09           ` Jeff King
2018-10-20 10:52             ` Ævar Arnfjörð Bjarmason
2018-10-19 22:07         ` Jeff King
2018-10-20 11:14           ` Ævar Arnfjörð Bjarmason
2018-10-20 18:58             ` Jeff King
2018-10-20 19:18               ` Ævar Arnfjörð Bjarmason
2018-10-22 21:15                 ` Jeff King
2018-10-22 21:28                   ` Ævar Arnfjörð Bjarmason
2018-10-22  1:23               ` Junio C Hamano
2018-10-26  8:39               ` Jeff King
2018-10-26 12:44                 ` Ævar Arnfjörð Bjarmason
2018-10-29  3:44                 ` Junio C Hamano
2018-10-29 14:17                   ` Jeff King
2018-09-05 21:51   ` [RFC PATCH v2] Allow aliases that include other aliases Junio C Hamano
2018-09-06 10:16 ` [PATCH v3] " Tim Schumacher
2018-09-06 14:01   ` Ævar Arnfjörð Bjarmason
2018-09-06 14:57     ` Jeff King
2018-09-06 15:10       ` Ævar Arnfjörð Bjarmason
2018-09-06 16:18         ` Jeff King
2018-09-06 19:05       ` Tim Schumacher [this message]
2018-09-06 19:17         ` Jeff King
2018-09-06 14:59   ` Jeff King
2018-09-06 18:40     ` Junio C Hamano
2018-09-06 19:05       ` Jeff King
2018-09-06 19:31       ` Tim Schumacher
2018-09-07 22:44 ` [RFC PATCH v4 1/3] Add support for nested aliases Tim Schumacher
2018-09-07 22:44   ` [RFC PATCH v4 2/3] Show the call history when an alias is looping Tim Schumacher
2018-09-08 13:34     ` Duy Nguyen
2018-09-08 16:29       ` Jeff King
2018-09-07 22:44   ` [RFC PATCH v4 3/3] t0014: Introduce alias testing suite Tim Schumacher
2018-09-07 23:38     ` Eric Sunshine
2018-09-14 23:12       ` Tim Schumacher
2018-09-16  7:21         ` Eric Sunshine
2018-09-08 13:28   ` [RFC PATCH v4 1/3] Add support for nested aliases Duy Nguyen
2018-09-16  7:46     ` Tim Schumacher
2018-09-17 15:37       ` Junio C Hamano
2018-09-21 12:45         ` Tim Schumacher
2018-09-21 15:59           ` Junio C Hamano
2018-09-16  7:50   ` [PATCH v5 " Tim Schumacher
2018-09-16  7:50     ` [PATCH v5 2/3] Show the call history when an alias is looping Tim Schumacher
2018-09-16  7:50     ` [PATCH v5 3/3] t0014: Introduce an alias testing suite Tim Schumacher

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=dea58ad8-4e2a-955a-8dc6-b93e9592398c@gmx.de \
    --to=timschumi@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    /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).