Re: [PATCH] send-pack: Filter unknown commits from alternates of the remote

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Björn Steinbrink <B.Steinbrink@xxxxxx> writes:

> Uhm, it might be obvious, but what exactly could go wrong?

Between the refs and your object store, there is a contract that
guarantees that everything that is reachable from your refs are complete
and you won't hit unreachable object while traversing the reachability
chain from them.  But your object store can contain other garbage
objects.  The contract is one of the things "git fsck" checks.

Imagine you have fetched from somewhere with a commit walker (e.g. fetch
over http), that started fetching from the tip commit and its associated
objects, and then got interrupted.  Such a transfer will leave the objects
in your local repository but it is safe because it won't update your refs.

>> I'd prefer a small helper function to consolidate the duplicated code,
>> like the attached patch, though.  How about doing it like this?
>
> Yeah, that looks a lot nicer :-)

But it was broken.  The initial check feed_object() does with
has_sha1_file() and NEEDSWORK comment needs to be inside

	if (negative) {
		if (!has_sha1_file(theirs))
			return 1;
		/*
		 * NEEDSWORK: we should not be satisfied by simply having
		 * theirs, but should be making sure it is reachable from
		 * some of our refs.
		 */
	}

to make sure we won't trigger the availability or connectivity check for
positive refs.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux