Re: [PATCH v5 1/3] ls-refs: report unborn targets of symrefs

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

 



Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes:

>> So a dangling symref, e.g. "refs/remotes/origin/HEAD -> trunk" when
>> no "refs/remotes/origin/trunk" exists, is not reported to send_ref()
>> in the same way as an unborn "HEAD"?
>
> I've tried it, and yes, for_each_namespaced_ref() will not report it.
> Looking at the code, I think it is packed_ref_iterator_advance() which
> checks for broken objects and skips over them.
>
>> I would have expected that we'd
>> report where it points at, and for that to work, you'd have to use
>> not just the vanilla send_ref() as the callback, but something that
>> knows how to do "are we expected to send unborn symrefs" logic, like
>> send_possibly_unborn_head does.
>> 
>> That "changed to tolerate ... should work" worries me.
>> 
>> If "for_each_namespaced_ref(send_ref, &data)" will never call send_ref()
>> with NULL (as in (void *)0) oid, then that would be OK,
>
> If it called send_ref() with (void *)0 OID, it would segfault with the
> current code, which calls oid_to_hex() on the OID unconditionally.
>
>> but if it
>> ends up calling with NULL somehow, it is responsible to ensure that
>> data->symrefs is true and flag has REF_ISSYMREF set, or send_ref()
>> would misbehave, (see the first part of your message, which I am
>> responding to), no?
>
> If it did, then yes.

So, in other words, the series is *only* about HEAD and no other
symrefs are reported when dangling as "unborn"?



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

  Powered by Linux