Junio C Hamano <gits...@pobox.com> writes: > Stefan Beller <sbel...@google.com> writes: > >> On Thu, Jul 13, 2017 at 8:01 AM, Jeff King <p...@peff.net> wrote: >> >>> builtin/branch.c | 14 +++++++------- >>> builtin/for-each-ref.c | 22 ++++++++++++---------- >>> builtin/tag.c | 30 ++++++++++++++++-------------- >>> builtin/verify-tag.c | 12 ++++++------ >>> ref-filter.c | 22 ++++++++++++---------- >>> ref-filter.h | 22 +++++++++++++++++----- >>> 6 files changed, 70 insertions(+), 52 deletions(-) >> >> The patch looks good to me. So some off-topic comments: >> I reviewed this patch from bottom up, i.e. I started looking at >> ref-filter.h, then ref-filter.c and then the rest. If only you had formatted >> the patches with an orderfile. ;) > > As a reviewer, for this particular patchq, I actually appreciated > that ref-filter.[ch] came at the end. That forced me to think. > ... > I do want to present from Doc to header to code when I am showing my > patch to others, so this is probably a good example that illustrates > that the preferred presentation order is not just personal > preference, but is different on occasion even for the same person.
So when somebody wants to do a "from design and explanation to provider to consumer", we would probably want "doc, *.h, *.c at the top-level and then things inside builtin/ subdirectory" order. Of course, on the other hand, "I do not trust me not getting swayed by the fact that a developer more competent than me wrote the patch" reviewer would want to use the reverse order. Can we actually express "top-level first and then builtin/*" order with the diff.orderfile mechanism? It's been a while since I last looked at the orderfile matching (which was when I originally wrote it) and I do not offhand know if we now allow wildmatch patterns and the directory level anchoring "/*.c" like we do in .gitignore files, without which it would be cumbersome to make ref-filter.c listed before builtin/branch.c in a generic way.
