[PATCH 06/16] Look up refs in namespace with cgit_get_sha1

Richard richard.maw at gmail.com
Fri Jul 29 18:54:07 CEST 2016


Adding CC to the list, since I forgot it, and have more to add.

On 29 July 2016 at 16:34, Richard <richard.maw at gmail.com> wrote:
> Apologies in advance if Gmail mangles this, I only have access to
> webmail at the moment.
>
> On 29 July 2016 at 15:32, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> On Sat, Jul 16, 2016 at 12:59 AM, Richard Maw <richard.maw at gmail.com> wrote:
>>> +static int namespaced_dwim_ref_get_sha1(const char *name, unsigned char *sha1)
> <snip>
>>> +               return namespaced_dwim_ref_get_sha1(name, sha1);
>>
>> Ugh. This manual ref lookup is really ugly and unfortunate. I don't
>> like having to duplicate the code like this. What would you think of
>> adding the flag to upstream, so that the functions are namespace
>> aware, and then this becomes unnecessary?
>
> I'll have a go. I don't know how successful adding a feature for a
> different project would be.

We're hoping to have this in the next Debian release.
Git releases look to have a few months between them,
so if it takes another few months for a Git release then it could miss
the deadline.

After I've worked out how to add the support to libgit I'll know better,
but it might be a good idea to:

1.  Make a patch to add support to libgit
2.  Port that patch into cgit,
    so when the libgit patch is submitted I can point to cgit
    to say that we're using cgit as a proving ground for the change.
3.  Submit namespace support patch to libgit.
4.  When there's a release with namespace support,
    update to it and remove the patch from cgit.

I'm not sure whether it would be better to transplant that part of
libgit into cgit,
or to patch libgit at build time.

>>> +       } else {
>>> +               return get_sha1(name, sha1);
>>> +       }
>>
>>
>> Get rid of the else clause, and just put "return get_sha1(name,
>> sha1);" unintended as the last line of the function.
>
> Sure, I failed to spot the coding style you preferred, I don't
> remember seeing it documented anywhere.


More information about the CGit mailing list