Re: [PATCH v3 14/23] log_ref_write_1(): don't depend on logfile argument

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

 



On 12/31/2016 07:35 AM, Jeff King wrote:
> On Sat, Dec 31, 2016 at 04:12:54AM +0100, Michael Haggerty wrote:
> 
>> It's unnecessary to pass a strbuf holding the reflog path up and down
>> the call stack now that it is hardly needed by the callers. Remove the
>> places where log_ref_write_1() uses it, in preparation for making it
>> internal to log_ref_setup().
>>
>> Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
>> ---
>>  refs/files-backend.c | 12 ++++++++----
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/refs/files-backend.c b/refs/files-backend.c
>> index 7f26cf8..5a96424 100644
>> --- a/refs/files-backend.c
>> +++ b/refs/files-backend.c
>> @@ -2837,14 +2837,18 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
>>  	result = log_ref_write_fd(logfd, old_sha1, new_sha1,
>>  				  git_committer_info(0), msg);
>>  	if (result) {
>> -		strbuf_addf(err, "unable to append to '%s': %s", logfile->buf,
>> -			    strerror(errno));
>> +		int save_errno = errno;
>> +
>> +		strbuf_addf(err, "unable to append to '%s': %s",
>> +			    git_path("logs/%s", refname), strerror(save_errno));
> 
> Hmm. This means the logic of "the path for a reflog is
> git_path(logs/%s)" is now replicated in several places. Which feels kind
> of like a backwards step. But I guess it is pretty well cemented in the
> concept of files-backend.c, and I do like the later cleanups that this
> allows.

This might end up in a helper function in the not-too-distant future for
other reasons, but given that such code already appears multiple times,
I didn't feel too guilty about it.

Michael





[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]