git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Vadim Petrov <tridronet@yandex.ru>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] setup.c: move statement under condition
Date: Wed, 27 Dec 2017 10:57:20 -0800	[thread overview]
Message-ID: <xmqqvagsm227.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1.1712232332000.406@MININT-6BKU6QN.europe.corp.microsoft.com> (Johannes Schindelin's message of "Sat, 23 Dec 2017 23:48:18 +0100 (STD)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> I suppose that if the condition is fulfilled then the previously
>> obtained value will not be necessary.
>
> I have to be honest: this commit message (including the subject) left me
> quite puzzled as to the intent of this patch.
>
> Maybe something like this would have spared me that puzzlement:
>
> 	Avoid unnecessary offset_1st_component() when prefixing filenames
>
> 	In the abspath_part_inside_repo() function that is called
> 	somewhere deep in the call-chain when prefixing paths, we
> 	calculate the offset of the first component, but under certain
> 	circumstances, the result is not even used.
>
> 	This patch changes the code to avoid that.

Sensible.

>> diff --git a/setup.c b/setup.c
>> index 8cc34186c..1ce0189fa 100644
>> --- a/setup.c
>> +++ b/setup.c
>> @@ -35,7 +35,6 @@ static int abspath_part_inside_repo(char *path)
>>  		return -1;
>>  	wtlen = strlen(work_tree);
>>  	len = strlen(path);
>> -	off = offset_1st_component(path);
>>  
>>  	/* check if work tree is already the prefix */
>>  	if (wtlen <= len && !strncmp(path, work_tree, wtlen)) {
>> @@ -49,6 +48,8 @@ static int abspath_part_inside_repo(char *path)
>>  		}
>>  		/* work tree might match beginning of a symlink to work tree */
>>  		off = wtlen;
>> +	} else {
>> +		off = offset_1st_component(path);
>>  	}
>
> Up until recently, we encouraged dropping the curly brackets from
> single-line statements, but apparently that changed. 

That is not quite correct.  We do encourage 

	if (...)
		single statement;

with or without

	else
		another single statement;

IOW, when both sides do not need curlies, we save vertical space.
On the other hand, when one side needs curlies, we tend to add to
both to make it easier to spot the correspondence, i.e.

	if (...) {
		compond statement;
		compond statement;
	} else {
		single statement;
	}

or the other way around.


	if (...) {
		single statement;
	} else {
		compond statement;
		compond statement;
	}

> However, we still encourage to put shorter alternative code paths
> (i.e. the blocks after `if` and `else`) first, in your case:
>
> @@ -35,18 +35,19 @@ static int abspath_part_inside_repo(char *path)
>  		return -1;
>  	wtlen = strlen(work_tree);
>  	len = strlen(path);
> -	off = offset_1st_component(path);
>  
>  	/* check if work tree is already the prefix */
> - 	if (wtlen <= len && !strncmp(path, work_tree, wtlen)) {
> +	if (wtlen > len || strncmp(path, work_tree, wtlen))
> +		off = offset_1st_component(path);
> +	else {
>  		if (path[wtlen] == '/') {
>  			memmove(path, path + wtlen + 1, len - wtlen);
>  			return 0;
> 		} else if (path[wtlen - 1] == '/' || path[wtlen] == '\0') {
> 			/* work tree is the root, or the whole path */
> 			memmove(path, path + wtlen, len - wtlen + 1);
> 			return 0;
> 		}
> 		/* work tree might match beginning of a symlink to work * tree */
> 		off = wtlen;
> 	}

This also may allow you to further dedent the if/else chain and make
the result easier to follow.  I dunno.

Thanks for a review.

      parent reply	other threads:[~2017-12-27 18:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-23 20:02 [PATCH] setup.c: move statement under condition Vadim Petrov
2017-12-23 22:48 ` Johannes Schindelin
2017-12-24  8:15   ` Vadim Petrov
2017-12-24 17:11     ` Kevin Daudt
2017-12-24 19:35       ` Ævar Arnfjörð Bjarmason
2017-12-25 17:52         ` Martin Werner
2017-12-27 18:57   ` Junio C Hamano [this message]

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=xmqqvagsm227.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=tridronet@yandex.ru \
    /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).