On 05/21/2015 12:37 AM, Eric Sunshine wrote:
On Wed, May 20, 2015 at 9:18 AM, Karthik Nayak <karthik....@gmail.com> wrote:
add a ref-filter API to provide functions to filter refs for listing.
This will act as a common library for commands like 'tag -l',
'branch -l' and 'for-each-ref'. ref-filter will enable each of these
commands to benefit from the features of the others.
Mentored-by: Christian Couder <christian.cou...@gmail.com>
Mentored-by: Matthieu Moy <matthieu....@grenoble-inp.fr>
Signed-off-by: Karthik Nayak <karthik....@gmail.com>
---
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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
