Re: [PATCH 2/4] ref-filter: add ref-filter API

> On Thu, May 21, 2015 at 1:30 PM, karthik nayak <karthik.188@gmail.com> wrote:
>> On 05/21/2015 12:37 AM, Eric Sunshine wrote:
>>> On Wed, May 20, 2015 at 9:18 AM, Karthik Nayak <karthik.188@gmail.com>
>>> wrote:
>>>>    Makefile     |  1 +
>>>>    ref-filter.c | 73
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>    ref-filter.h | 47 ++++++++++++++++++++++++++++++++++++++
>>>>    3 files changed, 121 insertions(+)
>>>>    create mode 100644 ref-filter.c
>>>>    create mode 100644 ref-filter.h
>>>
>>> A shortcoming of this approach is that it's not blame-friendly.
>>> Although those of us following this patch series know that much of the
>>> code in this patch was copied from for-each-ref.c, git-blame will not
>>> recognize this unless invoked in the very expensive "git blame -C -C
>>> -C" fashion (if I understand correctly). The most blame-friendly way
>>> to perform this re-organization is to have the code relocation (line
>>> removals and line additions) occur in one patch.
>>>
>>> There are multiple ways you could arrange to do so. One would be to
>>> first have a patch which introduces just a skeleton of the intended
>>> API, with do-nothing function implementations. A subsequent patch
>>> would then relocate the code from for-each-ref.c to ref-filter.c, and
>>> update for-each-ref.c to call into the new (now fleshed-out) API.
>>
>> Did you read Junio's suggestion on how I should re-order this WIP patch
>> series ?
>> That's somewhat on the lines of what you're suggesting. I'll probably be
>> going ahead with that, not really sure about how blame works entirely so
>> what do you think about that?
>
> Yes, Junio's response did a much better job of saying what I intended.
> Also, his response said something I meant to mention but forgot:
> namely that, to ease the review task, code movement should be pure
> movement, and not involve other changes.
>
> Anyhow, follow Junio's advice. He knows what he's talking about. ;-)
>