git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/RFC] branch.c: Replace `git_config` with `git_config_get_string`

From
Tanay Abhra <tanayabh@gmail.com>
Date
Jun 16, 2014, 17:49 UTC
Message-ID
<539F2E1F.7010604@gmail.com>
In-Reply-To
<vpqfvj4226o.fsf@anie.imag.fr>
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.
Show 7 quoted lines
> 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.

Show 15 quoted lines
>> 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.
Show 36 quoted lines
>>  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.

Previous: Matthieu Moy
Message 3 of 3 in “branch.c: Replace `git_config` with `git_config_get_string`”
  1. branch.c: Replace `git_config` with `git_config_get_string`Tanay Abhra, Jun 16, 2014
  2. Matthieu MoyJun 16, 2014
  3. Tanay AbhraJun 16, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.