Michael Haggerty writes:
> The point is that `read_ref_full()` is now called with
> `RESOLVE_REF_NO_RECURSE` turned on. So if `newrefname` is a symbolic
> reference, then `read_ref_full()` sets `sha1` to zeros.
Yes, that was an obvious rationale in the patch that was not
explained in the propose
On 04/30/2016 01:21 AM, David Turner wrote:
> On Fri, 2016-04-29 at 09:38 +0200, Michael Haggerty wrote:
>> On 04/27/2016 08:55 PM, Junio C Hamano wrote:
>>> Michael Haggerty writes:
>>>
@@ -2380,8 +2381,8 @@ int rename_ref(const char *oldrefname,
const char *newrefname, const char *logm
On Fri, 2016-04-29 at 09:38 +0200, Michael Haggerty wrote:
> On 04/27/2016 08:55 PM, Junio C Hamano wrote:
> > Michael Haggerty writes:
> >
> > > @@ -2380,8 +2381,8 @@ int rename_ref(const char *oldrefname,
> > > const char *newrefname, const char *logms
> > > goto rollback;
> > > }
>
Michael Haggerty writes:
> On 04/29/2016 02:12 PM, Jeff King wrote:
>> On Fri, Apr 29, 2016 at 12:57:29PM +0200, Michael Haggerty wrote:
>>
>>> Remember, we're talking about rename_ref() only, not reference deletion
>>> in general. rename_ref() is not very robust anyway--it doesn't happen in
>>>
On Fri, Apr 29, 2016 at 03:55:00PM +0200, Michael Haggerty wrote:
> It's beyond the ambition of this patch to fix this old rename_ref()
> code, but...
> [...]
Thanks for the explanation. That all makes sense to me, and I can
definitely live with "historical warts that aren't worth touching in
thi
On 04/29/2016 02:12 PM, Jeff King wrote:
> On Fri, Apr 29, 2016 at 12:57:29PM +0200, Michael Haggerty wrote:
>
>> Remember, we're talking about rename_ref() only, not reference deletion
>> in general. rename_ref() is not very robust anyway--it doesn't happen in
>> a single transaction, and it is v
On Fri, Apr 29, 2016 at 12:57:29PM +0200, Michael Haggerty wrote:
> Remember, we're talking about rename_ref() only, not reference deletion
> in general. rename_ref() is not very robust anyway--it doesn't happen in
> a single transaction, and it is vulnerable to being defeated by
> simultaneous re
On 04/29/2016 10:53 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>>> Could you explain s/sha1/NULL/ here in the proposed log message?
>>
>> Good question.
>>
>> Passing sha1 to delete_ref() doesn't add any safety, because the same
>> sha1 was just read a moment before, and it is not use
Michael Haggerty writes:
>> Could you explain s/sha1/NULL/ here in the proposed log message?
>
> Good question.
>
> Passing sha1 to delete_ref() doesn't add any safety, because the same
> sha1 was just read a moment before, and it is not used for anything
> else.
"... and it is guaranteed that n
On 04/27/2016 08:55 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> @@ -2380,8 +2381,8 @@ int rename_ref(const char *oldrefname, const char
>> *newrefname, const char *logms
>> goto rollback;
>> }
>>
>> -if (!read_ref_full(newrefname, RESOLVE_REF_READING, sha1,
Michael Haggerty writes:
> @@ -2380,8 +2381,8 @@ int rename_ref(const char *oldrefname, const char
> *newrefname, const char *logms
> goto rollback;
> }
>
> - if (!read_ref_full(newrefname, RESOLVE_REF_READING, sha1, NULL) &&
> - delete_ref(newrefname, sha1, REF
From: David Turner
When renaming refs, don't dereference either the origin or the destination
before renaming.
The origin does not need to be dereferenced because it is presently
forbidden to rename symbolic refs.
Not dereferencing the destination fixes a bug where renaming on top of
a broken s
12 matches
Mail list logo
