When we mark all reachable objects for pruning, that
includes blobs mentioned by the index. However, we do not
mark these with the SEEN flag, as we do for objects that we
find by traversing (we also do not add them to the pending
list, but that is because there is nothing further to
traverse with them).

This doesn't cause any problems with prune, because it
checks only that the object exists in the global object
hash, and not its flags. However, let's mark these objects
to be consistent and avoid any later surprises.

Signed-off-by: Jeff King <p...@peff.net>
---
This code actually gets dropped later on in the series (when we teach
the revision machinery to look at index objects), so this could
technically be omitted. But it also keeps the minor behavior change
here by itself, where it is explained, instead of as a side effect of
the movement.

 reachable.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/reachable.c b/reachable.c
index 4e68cfa..d03f829 100644
--- a/reachable.c
+++ b/reachable.c
@@ -55,6 +55,8 @@ static void add_cache_refs(struct rev_info *revs)
 
        read_cache();
        for (i = 0; i < active_nr; i++) {
+               struct blob *blob;
+
                /*
                 * The index can contain blobs and GITLINKs, GITLINKs are hashes
                 * that don't actually point to objects in the repository, it's
@@ -65,7 +67,10 @@ static void add_cache_refs(struct rev_info *revs)
                if (S_ISGITLINK(active_cache[i]->ce_mode))
                        continue;
 
-               lookup_blob(active_cache[i]->sha1);
+               blob = lookup_blob(active_cache[i]->sha1);
+               if (blob)
+                       blob->object.flags |= SEEN;
+
                /*
                 * We could add the blobs to the pending list, but quite
                 * frankly, we don't care. Once we've looked them up, and
-- 
2.1.2.596.g7379948

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to