From: Jonathan Nieder <jrnieder@gmail.com>
Date: Tue, 28 Aug 2018 21:24:57 GMT
Subject: Re: [PATCH v2 04/18] commit-reach: move commit_contains from ref-filter
Message-ID: <20180828212457.GA74687@aiede.svl.corp.google.com>
In-Reply-To: <20180720163227.105950-5-dstolee@microsoft.com>

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 <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