* [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string`
@ 2014-06-16 8:52 Tanay Abhra
2014-06-16 17:29 ` Matthieu Moy
0 siblings, 1 reply; 3+ messages in thread
From: Tanay Abhra @ 2014-06-16 8:52 UTC (permalink / raw)
To: git; +Cc: Tanay Abhra, Ramkumar Ramachandra, Matthieu Moy
Original implementation uses a callback based approach which has some
deficiencies like a convoluted control flow and redundant variables.
Use git_config_get_string instead of git_config to take advantage of
the config hash-table.
---
This patch builds on top of patch series[1]. It passes all the tests, and
this in first of series of patches that aim to replace all git_config
calls scattered arund the code base with appropriate non-callback based
calls.
There are total 111 calls in total in all of git codebase. How should I send
the patches, alphabetically or otherwise?
[1] http://thread.gmane.org/gmane.comp.version-control.git/251704
Cheers,
Tanay Abhra.
branch.c | 25 +++++++++----------------
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/branch.c b/branch.c
index 660097b..257b1bf 100644
--- a/branch.c
+++ b/branch.c
@@ -140,33 +140,26 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
return 0;
}
-struct branch_desc_cb {
+struct branch_desc {
const char *config_name;
const char *value;
};
-static int read_branch_desc_cb(const char *var, const char *value, void *cb)
-{
- struct branch_desc_cb *desc = cb;
- if (strcmp(desc->config_name, var))
- return 0;
- free((char *)desc->value);
- return git_config_string(&desc->value, var, value);
-}
-
int read_branch_desc(struct strbuf *buf, const char *branch_name)
{
- struct branch_desc_cb cb;
+ const char *value;
+ struct branch_desc desc;
struct strbuf name = STRBUF_INIT;
strbuf_addf(&name, "branch.%s.description", branch_name);
- cb.config_name = name.buf;
- cb.value = NULL;
- if (git_config(read_branch_desc_cb, &cb) < 0) {
+ desc.config_name = name.buf;
+ desc.value = NULL;
+ value = git_config_get_string(desc.config_name);
+ git_config_string(&desc.value, desc.config_name, value);
+ if (!desc.value) {
strbuf_release(&name);
return -1;
}
- if (cb.value)
- strbuf_addstr(buf, cb.value);
+ strbuf_addstr(buf, desc.value);
strbuf_release(&name);
return 0;
}
--
1.9.0.GIT
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string`
2014-06-16 8:52 [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string` Tanay Abhra
@ 2014-06-16 17:29 ` Matthieu Moy
2014-06-16 17:49 ` Tanay Abhra
0 siblings, 1 reply; 3+ messages in thread
From: Matthieu Moy @ 2014-06-16 17:29 UTC (permalink / raw)
To: Tanay Abhra; +Cc: git, Ramkumar Ramachandra
> Subject: Re: [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string`
Here and elsewhere: usually, no capital after :.
Tanay Abhra <tanayabh@gmail.com> writes:
> Original implementation uses a callback based approach which has some
> deficiencies like a convoluted control flow and redundant variables.
"deficiencies" might be a bit strong (the code did work).
> There are total 111 calls in total in all of git codebase. How should I send
> the patches, alphabetically or otherwise?
My advice would be: try as much as possible to split according to the
complexity of the patch.
As a reviewer, I find it rather easy to review a large number of trivial
and similar changes, but I hate having to switch back to "wow, the
author did something tricky, let's try to understand this" in the middle
of a trivial series.
(we had this discussion about `...` Vs $(...) and test -a Vs test ... &&
series, which were essentially very trivial changes, but with subtle
bugs introduced and hidden by the volume of trivial changes).
> branch.c | 25 +++++++++----------------
> 1 file changed, 9 insertions(+), 16 deletions(-)
Removing more lines than it adds. I like the patch already ;-).
> diff --git a/branch.c b/branch.c
> index 660097b..257b1bf 100644
> --- a/branch.c
> +++ b/branch.c
[...]
> int read_branch_desc(struct strbuf *buf, const char *branch_name)
> {
> - struct branch_desc_cb cb;
> + const char *value;
> + struct branch_desc desc;
> struct strbuf name = STRBUF_INIT;
> strbuf_addf(&name, "branch.%s.description", branch_name);
> - cb.config_name = name.buf;
> - cb.value = NULL;
> - if (git_config(read_branch_desc_cb, &cb) < 0) {
> + desc.config_name = name.buf;
> + desc.value = NULL;
> + value = git_config_get_string(desc.config_name);
> + git_config_string(&desc.value, desc.config_name, value);
You're ignoring the return value of git_config_string, which is an error
code. It shouldn't harm, because the code is non-zero iff desc.value is
set to non-NULL, but you may want to write the code as
if (git_config_string(...)) {
strbuf_release(...);
return -1;
}
In any case, the patch sounds good to me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string`
2014-06-16 17:29 ` Matthieu Moy
@ 2014-06-16 17:49 ` Tanay Abhra
0 siblings, 0 replies; 3+ messages in thread
From: Tanay Abhra @ 2014-06-16 17:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Ramkumar Ramachandra
On 06/16/2014 10:29 AM, Matthieu Moy wrote:
>> Subject: Re: [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string`
>
> Here and elsewhere: usually, no capital after :.
>
Noted.
> Tanay Abhra <tanayabh@gmail.com> writes:
>
>> Original implementation uses a callback based approach which has some
>> deficiencies like a convoluted control flow and redundant variables.
>
> "deficiencies" might be a bit strong (the code did work).
>
Hehe, I did spell out what the "deficiencies" were, nevertheless will revise it in
next iteration.
>> There are total 111 calls in total in all of git codebase. How should I send
>> the patches, alphabetically or otherwise?
>
> My advice would be: try as much as possible to split according to the
> complexity of the patch.
>
> As a reviewer, I find it rather easy to review a large number of trivial
> and similar changes, but I hate having to switch back to "wow, the
> author did something tricky, let's try to understand this" in the middle
> of a trivial series.
>
> (we had this discussion about `...` Vs $(...) and test -a Vs test ... &&
> series, which were essentially very trivial changes, but with subtle
> bugs introduced and hidden by the volume of trivial changes).
>
Noted.
>> branch.c | 25 +++++++++----------------
>> 1 file changed, 9 insertions(+), 16 deletions(-)
>
> Removing more lines than it adds. I like the patch already ;-).
>
>> diff --git a/branch.c b/branch.c
>> index 660097b..257b1bf 100644
>> --- a/branch.c
>> +++ b/branch.c
> [...]
>> int read_branch_desc(struct strbuf *buf, const char *branch_name)
>> {
>> - struct branch_desc_cb cb;
>> + const char *value;
>> + struct branch_desc desc;
>> struct strbuf name = STRBUF_INIT;
>> strbuf_addf(&name, "branch.%s.description", branch_name);
>> - cb.config_name = name.buf;
>> - cb.value = NULL;
>> - if (git_config(read_branch_desc_cb, &cb) < 0) {
>> + desc.config_name = name.buf;
>> + desc.value = NULL;
>> + value = git_config_get_string(desc.config_name);
>> + git_config_string(&desc.value, desc.config_name, value);
>
> You're ignoring the return value of git_config_string, which is an error
> code. It shouldn't harm, because the code is non-zero iff desc.value is
> set to non-NULL, but you may want to write the code as
>
> if (git_config_string(...)) {
> strbuf_release(...);
> return -1;
> }
>
> In any case, the patch sounds good to me.
>
Yes, for clarity sake, will rewrite the section like that.
Thanks for the review.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-06-16 17:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-16 8:52 [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string` Tanay Abhra
2014-06-16 17:29 ` Matthieu Moy
2014-06-16 17:49 ` Tanay Abhra
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).