Re: [PATCH v2 04/18] commit-reach: move commit_contains from ref-filter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <dstolee@xxxxxxxxxxxxx>
---
  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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux