On Thu, 27 Jul 2017 12:17:37 -0700
Junio C Hamano <[email protected]> wrote:
> The same comment as 2/4 applies here.
Noted - whatever the resolution is, I'll apply it to all the patches.
>
> > @@ -212,6 +221,8 @@ static void check_reachable_object(struct object *obj)
> > * do a full fsck
> > */
> > if (!(obj->flags & HAS_OBJ)) {
> > + if (repository_format_lazy_object)
> > + return;
> > if (has_sha1_pack(obj->oid.hash))
> > return; /* it is in pack - forget about it */
> > printf("missing %s %s\n", printable_type(obj),
>
> Also this reminds as a related issue. Imagine:
>
> - An object X was once retrieved, perhaps but not necessarily
> lazily, together with another object Y that is referred to by X
> (e.g. X is a tree, Y is a blob in the directory at path D, which
> is represented by X).
>
> - The same blob Y is added to the index in a different directory at
> path E.
>
> - The user decides to make this a slimmed-down "narrow clone" style
> repository and tells Git that path D is not interesting. We lose
> X, but not Y because Y is still referenced from the index.
>
> - "git reset --hard" happens, and there no longer is any reference
> to Y.
>
> Now, when we run fsck, should we diagnose Y as "unreachable and/or
> dangling"?
I would say yes (or whatever happens in the case where we re-fetch into
a shallow clone).
Come to think of it..."git reset --hard" always has the potential to
create unreachable objects, right (regardless of whether it's a "shallow
clone" or "narrow clone" or ordinary clone)?
