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