Re: [RFC PATCH 3/4] fsck: support referenced lazy objects

[Jonathan Tan <jonathantanmy@google.com>]

On Thu, 27 Jul 2017 12:17:37 -0700
Junio C Hamano <gitster@pobox.com> 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)?