Re: [PATCH v20 39/48] refs.c: make delete_ref use a transaction
- From
Ronnie Sahlberg <sahlberg@google.com>
- Date
- Jul 14, 2014, 20:50 UTC
- Message-ID
- <CAL=YDWmVpB3uj_was-Tyqkgxhd9-5LN6Pg0scG0JkzeWDp0pqA@mail.gmail.com>
- In-Reply-To
- <53BBF794.1090702@alum.mit.edu>
On Tue, Jul 8, 2014 at 6:52 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 44 quoted lines
> On 06/20/2014 04:43 PM, Ronnie Sahlberg wrote:
>> Change delete_ref to use a ref transaction for the deletion. At the same time
>> since we no longer have any callers of repack_without_ref we can now delete
>> this function.
>>
>> Change delete_ref to return 0 on success and 1 on failure instead of the
>> previous 0 on success either 1 or -1 on failure.
>>
>> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>> Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
>> ---
>> refs.c | 34 +++++++++++++---------------------
>> 1 file changed, 13 insertions(+), 21 deletions(-)
>>
>> diff --git a/refs.c b/refs.c
>> index 3d070d5..92a06d4 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -2544,11 +2544,6 @@ int repack_without_refs(const char **refnames, int n, struct strbuf *err)
>> return ret;
>> }
>>
>> -static int repack_without_ref(const char *refname)
>> -{
>> - return repack_without_refs(&refname, 1, NULL);
>> -}
>> -
>> static int delete_ref_loose(struct ref_lock *lock, int flag)
>> {
>> if (!(flag & REF_ISPACKED) || flag & REF_ISSYMREF) {
>> @@ -2566,24 +2561,21 @@ static int delete_ref_loose(struct ref_lock *lock, int flag)
>>
>> int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
>> {
>> - struct ref_lock *lock;
>> - int ret = 0, flag = 0;
>> + struct ref_transaction *transaction;
>> + struct strbuf err = STRBUF_INIT;
>>
>> - lock = lock_ref_sha1_basic(refname, sha1, delopt, &flag);
>
> The old code checked that the old value of refname was sha1, regardless
> of whether sha1 was null_sha1. Presumably callers never set sha1 to
> null_sha1...They sometimes do.
Show 10 quoted lines
> >> - if (!lock) >> + transaction = ref_transaction_begin(&err); >> + if (!transaction || >> + ref_transaction_delete(transaction, refname, sha1, delopt, >> + sha1 && !is_null_sha1(sha1), &err) || > > ...But the new code explicitly skips the check if sha1 is null_sha1. > This shouldn't make a practical difference, because presumably callers > never set sha1 to null_sha1.
There are actually a few cases where callers do call delete_ref() with sha1 == null_sha1. For example fast-import.c:update_branch() will do this is the ref can not be resolved. It can also happen in builtin/update-ref.c where we are passing user supplied data into the call to delete_ref.
So I think the current behaviour should be ok.
There are a few options we could do: We could change the semantics for ref_transaction_update|delete and start allowing have_old==1 old_sha1==null_sha1 and have this behave the same way as have_old==0 but I think that would be horrible I think.
We could also change all callers to delete_ref() to be careful to only specify a sha1 IFF it is not null_sha1 but that would just mean we require all callers to do this type of check. But that would also be fragile since if/when we get new callers to delete_ref we risk breaking delete_ref if we are not careful.
I think the least bad option is to just have this check in delete_ref() as now and have the semantics for delete_ref be that if sha1 is either NULL or null_sha1 then it means we don't care what the old value is.
regards ronnie sahlberg