refs: mark the file-local vtable symbols as static
PATCH 1/1 refs: mark the file-local vtable symbols as static
---
Hi Michael, Junio,
I would normally ask you to squash this into the relevant patch when you next re-roll your 'mh/ref-iterators' branch, but this has already been merged into next. (I normally have a bit more time ... sorry!).
Perhaps, after the release, when the next branch is re-wound/re-built, this could be squashed into your branch then.
Anyway, after applying this patch, the following symbols are still 'public but unused':
> refs/files-backend.o - files_reflog_iterator_begin
> refs/iterator.o - is_empty_ref_iterator
> refs/iterator.o - merge_ref_iterator_begin
These all look (potentially) useful for the implementation of additional 'ref-iter' types and look to be part of the _internal_ iterator API - so they should not be marked static. Can you just confirm my interpretation.
Thanks.
ATB,
Ramsay Jones
refs/files-backend.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
refs/files-backend.c +3 -3
@@ -711,7 +711,7 @@ static int cache_ref_iterator_abort(struct ref_iterator *ref_iterator)return ITER_DONE ; } -struct ref_iterator_vtable cache_ref_iterator_vtable = { +static struct ref_iterator_vtable cache_ref_iterator_vtable = { cache_ref_iterator_advance, cache_ref_iterator_peel, cache_ref_iterator_abort
@@ -1933,7 +1933,7 @@ static int files_ref_iterator_abort(struct ref_iterator *ref_iterator)return ok; } -struct ref_iterator_vtable files_ref_iterator_vtable = { +static struct ref_iterator_vtable files_ref_iterator_vtable = { files_ref_iterator_advance, files_ref_iterator_peel, files_ref_iterator_abort
@@ -3354,7 +3354,7 @@ static int files_reflog_iterator_abort(struct ref_iterator *ref_iterator)return ok; } -struct ref_iterator_vtable files_reflog_iterator_vtable = { +static struct ref_iterator_vtable files_reflog_iterator_vtable = { files_reflog_iterator_advance, files_reflog_iterator_peel, files_reflog_iterator_abort
Signature · 1 line
2.8.0
Quoted 11 lines · Ramsay Jones
Signed-off-by Ramsay Jones <[email protected]>---
Hi Michael, Junio,
I would normally ask you to squash this into the relevant patch when you next re-roll your 'mh/ref-iterators' branch, but this has already been merged into next. (I normally have a bit more time ... sorry!).
Perhaps, after the release, when the next branch is re-wound/re-built, this could be squashed into your branch then.
Yup, sounds like a plan.
Quoted 4 lines
Anyway, after applying this patch, the following symbols are still 'public but unused':
Quoted 8 lines
>
refs/files-backend.o-files_reflog_iterator_begin
>refs/iterator.o-is_empty_ref_iterator
>refs/iterator.o-merge_ref_iterator_beginThese all look (potentially) useful for the implementation of additional 'ref-iter' types and look to be part of the _internal_ iterator API - so they should not be marked static. Can you just confirm my interpretation.
I am not Michael, but FWIW I think that is sensible.
Quoted 24 lines · Junio C Hamano
Quoted 11 lines · Ramsay Jones
Signed-off-by Ramsay Jones <[email protected]>---
Hi Michael, Junio,
I would normally ask you to squash this into the relevant patch when you next re-roll your 'mh/ref-iterators' branch, but this has already been merged into next. (I normally have a bit more time ... sorry!).
Perhaps, after the release, when the next branch is re-wound/re-built, this could be squashed into your branch then.
Yup, sounds like a plan.
Quoted 8 lines
Anyway, after applying this patch, the following symbols are still 'public but unused':
>
refs/files-backend.o-files_reflog_iterator_begin
>refs/iterator.o-is_empty_ref_iterator
>refs/iterator.o-merge_ref_iterator_begin
Quoted 6 lines
Quoted 4 lines
These all look (potentially) useful for the implementation of additional 'ref-iter' types and look to be part of the _internal_ iterator API - so they should not be marked static. Can you just confirm my interpretation.
I am not Michael, but FWIW I think that is sensible.
I *am* Michael, and I think your changes look good. Thanks for your review.
I've incorporated your changes with some other changes in a re-roll [1] in case Junio wants to use it in that form. Please note that two of the hunks that you are suggesting apply to "refs: introduce an iterator interface" and the third to "for_each_reflog(): reimplement using iterators".
Michael
[1] http://article.gmane.org/gmane.comp.version-control.git/296883