Re: 2.22.0 repack -a duplicating pack contents

From: Jeff King <peff@peff.net>
Date: Jun 23, 2019, 22:42 UTC
Message-ID: <20190623224244.GB1100@sigill.intra.peff.net>
In-Reply-To: <20190623180825.3ospajjgat3clwiu@dcvr>

On Sun, Jun 23, 2019 at 06:08:25PM +0000, Eric Wong wrote:

Show 9 quoted lines

> > I'm not sure of the right solution. For maximal backwards-compatibility,
> > the default for bitmaps could become "if not bare and if there are no
> > .keep files". But that would mean bitmaps sometimes not getting
> > generated because of the problems that ee34a2bead was trying to solve.
> > 
> > That's probably OK, though; you can always flip the bitmap config to
> > "true" yourself if you _must_ have bitmaps.
> 
> What about something like this?  Needs tests but I need to leave, now.

Yeah, I think that's the right direction.

Though...

Show 18 quoted lines

> +static int has_pack_keep_file(void)
> +{
> +	DIR *dir;
> +	struct dirent *e;
> +	int found = 0;
> +
> +	if (!(dir = opendir(packdir)))
> +		return found;
> +
> +	while ((e = readdir(dir)) != NULL) {
> +		if (ends_with(e->d_name, ".keep")) {
> +			found = 1;
> +			break;
> +		}
> +	}
> +	closedir(dir);
> +	return found;
> +}

I think this can be replaced with just checking p->pack_keep for each item in the packed_git list.

That's racy, but then so is your code here, since it's really the child pack-objects which is going to deal with the .keep. I don't think we need to care much about the race, though. Either:

  1. Somebody has made an old intentional .keep, which would not be
     racy. We'd see it in both places.

  2. Somebody _just_ made an intentional .keep; we'll race with that and
     maybe duplicate objects from the kept pack. But this is a rare
     occurrence, and there's no real ordering promise here anyway with
     somebody creating .keep files alongside a running repack.

  3. An incoming fetch/push may create a .keep file as a temporary lock,
     which we see here but which goes away by the time pack-objects
     runs. That's OK; we err on the side of not generating bitmaps, but
     they're an optimization anyway (and if you really insist on having
     them, you should tell Git to definitely make them instead of
     relying on this default behavior).

  4. Like (3), but we _don't _see the temporary .keep here but _do_ see
     it during pack-objects. That's OK, because we'll have told
     pack-objects to pack those objects anyway, which is the right
     thing.

-Peff