From: Derrick Stolee Date: Tue, 28 Aug 2018 21:33:37 GMT Subject: Re: [PATCH v2 04/18] commit-reach: move commit_contains from ref-filter Message-ID: In-Reply-To: <20180828212457.GA74687@aiede.svl.corp.google.com> On 8/28/2018 5:24 PM, Jonathan Nieder wrote: > Hi, > > Derrick Stolee wrote: > >> There are several commit walks in the codebase. Group them together into >> a new commit-reach.c file and corresponding header. After we group these >> walks into one place, we can reduce duplicate logic by calling >> equivalent methods. >> >> All methods are direct moves, except we also make the commit_contains() >> method public so its consumers in ref-filter.c can still call it. We can >> also test this method in a test-tool in a later commit. >> >> Signed-off-by: Derrick Stolee >> --- >> commit-reach.c | 121 +++++++++++++++++++++++++++++++++++++++++ >> commit-reach.h | 20 ++++++- >> ref-filter.c | 145 +++---------------------------------------------- >> 3 files changed, 147 insertions(+), 139 deletions(-) >> >> diff --git a/commit-reach.c b/commit-reach.c >> index a6bc4781a6..01d796f011 100644 >> --- a/commit-reach.c >> +++ b/commit-reach.c >> @@ -1,8 +1,10 @@ >> #include "cache.h" >> #include "commit.h" >> +#include "commit-graph.h" >> #include "decorate.h" >> #include "prio-queue.h" >> #include "tree.h" >> +#include "ref-filter.c" > Did you mean "ref-filter.h"? > > This broke the build here. Is there some check that we can use to > prevent it happening again? I don't think we ever intentionally > #include a .c file. Woah! How did that ever work? I definitely built this locally.