Re: [PATCH v12 03/12] refs: document how ref_iterator_advance_fn should handle symrefs

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

 



Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> From: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
> ---
>  refs/refs-internal.h | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/refs/refs-internal.h b/refs/refs-internal.h
> index ff2436c0fb7..3490aac3a40 100644
> --- a/refs/refs-internal.h
> +++ b/refs/refs-internal.h
> @@ -438,6 +438,11 @@ void base_ref_iterator_free(struct ref_iterator *iter);
>  
>  /* Virtual function declarations for ref_iterators: */
>  
> +/*
> + * backend-specific implementation of ref_iterator_advance.
> + * For symrefs, the function should set REF_ISSYMREF, and it should also
> + * dereference the symref to provide the OID referent.
> + */
>  typedef int ref_iterator_advance_fn(struct ref_iterator *ref_iterator);
>  
>  typedef int ref_iterator_peel_fn(struct ref_iterator *ref_iterator,

Makes sense.

I wonder if I should take 1-3/12 as a separate "clean-up" series and
merge it before everything else down to 'master'?  That would reduce
the churn somewhat.

I also wonder if there are similar "clean-up" buried later in the
series. For example, would it make sense to also move 11/12 and have
it graduate early together with 1-3/12?

Thanks.




[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