Re: [PATCH v15 04/27] bisect--helper: `bisect_clean_state` shell function in C

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/15/2016 10:40 PM, Junio C Hamano wrote:
> Stephan Beyer <s-beyer@xxxxxxx> writes:
> 
>>> +int bisect_clean_state(void)
>>> +{
>>> +	int result = 0;
>>> +
>>> +	/* There may be some refs packed during bisection */
>>> +	struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
>>> +	for_each_ref_in("refs/bisect", mark_for_removal, (void *) &refs_for_removal);
>>> +	string_list_append(&refs_for_removal, xstrdup("BISECT_HEAD"));
>>> +	result = delete_refs(&refs_for_removal, REF_NODEREF);
>>> +	refs_for_removal.strdup_strings = 1;
>>> +	string_list_clear(&refs_for_removal, 0);
>>
>> Does it have advantages to populate a list (with duplicated strings),
>> hand it to delete_refs(), and clear the list (and strings), instead of
>> just doing a single delete_ref() (or whatever name the singular function
>> has) in the callback?
> 
> Depending on ref backends, removing multiple refs may be a lot more
> efficient than calling a single ref removal for the same set of
> refs, and the comment upfront I think hints that the code was
> written in the way exactly with that in mind.  Removing N refs from
> a packed refs file will involve a loop that runs N times, each
> iteration loading the file, locating an entry among possibly 100s of
> refs to remove, and then rewriting the file.

Great, that's the reply I wanted to hear (and that I've considered but
wasn't sure of) ;)
[I did not want to dig into the sources and check if delete_refs() does
something smarter than invoking delete_ref() on each item of the list.]

~Stephan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]