Re: [PATCH v2 04/18] commit-reach: move commit_contains from ref-filter
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Aug 28, 2018, 21:24 UTC
- Message-ID
- <20180828212457.GA74687@aiede.svl.corp.google.com>
- In-Reply-To
- <20180720163227.105950-5-dstolee@microsoft.com>
Hi,
Derrick Stolee wrote:
Show 28 quoted lines
> 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 <dstolee@microsoft.com> > --- > 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.
Thanks, Jonathan