Vasyl' Vavrychuk (4):
Reduce url_len variable scope
Extract function trim_url and optimize calls of it.
Dont use the same variable for different things
Replace pointer arithmetic with strbuf
builtin/fetch.c | 63 ++++++++++++++++++++++++++++++++----------------------
1 files changed, 37 insertions(+), 26 deletions(-)
Extract compact code into trim_url. Dont call it every iteration in the loop since no reason.
Signed-off-by: Vasyl' Vavrychuk <redacted>
---
builtin/fetch.c | 29 ++++++++++++++++++-----------
1 files changed, 18 insertions(+), 11 deletions(-)
Hi,
I've needed this as part of bigger change which is collecting all
.git/FETCH_HEAD related code across different files to
fetch-head.[ch]. Which in its case I do as part of git-pull.sh to C
porting. So thats motivation chain :)
On Sun, Feb 13, 2011 at 2:09 AM, Sverre Rabbelier [off-list ref] wrote:
Heya,
On Sat, Feb 12, 2011 at 23:38, Vasyl' Vavrychuk [off-list ref] wrote:
quoted
Vasyl' Vavrychuk (4):
Neither the patches, nor this cover letter explain _why_ this is being
done. Motivation needed :).
--
Cheers,
Sverre Rabbelier
Heya,
On Sun, Feb 13, 2011 at 19:37, Vasyl' [off-list ref] wrote:
I've needed this as part of bigger change which is collecting all
.git/FETCH_HEAD related code across different files to
fetch-head.[ch]. Which in its case I do as part of git-pull.sh to C
porting. So thats motivation chain :)
Thanks, that's the kind of stuff that should go into the cover letter
/ the patch description.
--
Cheers,
Sverre Rabbelier
Please mark the patch in such a way that the readers can tell what
file/function this patch is about by reading "git shortlog" output
without anything else, i.e.
Subject: builtin/fetch.c: shorten lifetime of the url_len variable
Hmph. While this does not bring in any new bug to the code, what benefit
do we gain from it?
The scope is not reduced (even though the variable's lifespan is shortened
in the scope). Are we so short of registers that this change matters?
From: Junio C Hamano <hidden> Date: 2016-06-15 22:50:35
Vasyl' Vavrychuk [off-list ref] writes:
Extract compact code into trim_url. Dont call it every iteration in the loop since no reason.
Too long a line; just drop " since no reason".
quoted hunk
@@ -379,14 +394,6 @@ static int store_updated_refs(const char *raw_url, const char *remote_name, what = rm->name; }- url_len = strlen(url);- for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)- ;- url_len = i + 1;- if (4 < i && !strncmp(".git", url + i - 3, 4))- url_len = i - 3;- url[url_len] = '\0';- note_len = 0; if (*what) { if (*kind)
We repeatedly called strlen(url) for each entry in the ref-map when we
know we do not have any more thing to do; silly. This is probably a good
thing to do.
From: Junio C Hamano <hidden> Date: 2016-06-15 22:50:35
Vasyl' Vavrychuk [off-list ref] writes:
Subject: Re: [PATCH 3/4] Dont use the same variable for different things
Subject: builtin/fetch.c: do not use ... different things
But more important question is why?
What benefit are we getting by almost doubling the stack footprint of this
function? What problem are you fixing?
From: João P. Sampaio <hidden> Date: 2016-06-15 22:50:35
On Wed, Feb 16, 2011 at 23:44, Junio C Hamano [off-list ref] wrote:
But more important question is why?
What benefit are we getting by almost doubling the stack footprint of this
function? What problem are you fixing?
Well, in matters of code readability and maintainability, it's best to
use different variables for different matters...
Nowadays, memory isn't really an issue anymore, is it? I think it's
valid to make code more readable, if memory cost isn't absurd.
--
João Paulo Melo de Sampaio
Computer Engineering Student @ UFSCar
Website: http://www.jpmelos.com
Twitter: http://twitter.com/jpmelos (@jpmelos)