Nicolas Pitre <nico@xxxxxxxxxxx> writes:
> On Mon, 11 Jan 2010, Junio C Hamano wrote:
>
>> Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> writes:
>>
>> > söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:
>> >> Hi List,
>> >> I am trying to find a way to check availability of new commits
>> >> *before* doing fetch or pull. Unfortunately, neither fetch nor pull
>> >> take "--dry-run" option (unlike push)
>> >
>> > Fetch has --dry-run. It's a fairly new option. The drawback is that it
>> > still does the fetch, but it does not update the refs. If you re.run it
>> > again it'll be quicker.
>>
>> Doesn't that worry us if it really is quicker?
>>
>> If --dry-run doesn't update the refs, why do the objects that were
>> transferred by them not get asked the next time? There must be a bug
>> somewhere, but it is getting late already, so I'll leave it to experts in
>> the transfer area to figure it out...
>
> What about builtin-fetch.c:quickfetch() ?
Ahh, you are right. It walks from objects the remote side told us are at
the tip, and stops at what we know are complete (i.e. reachable from our
tip of objects); immediately after --dry-run slurped objects, the next
fetch will prove everything is locally available and complete before going
over the network.
But either I am very confused or the use of fields from "struct ref" is
unintuitive in this codepath.
Why does it feed ref->old_sha1? We are feeding _their_ tip commits to:
rev-list --objects --stdin --not --all
and expecting it to report failure when some of their tip commits lead to
what we don't have yet. The reason why we have old_sha1[] vs new_sha1[]
is because we want to report what changed from what, and also to protect
us from simultaneous updates by doing compare-and-swap using the value we
read from our refs when we started in old_sha1[], so I would have expected
that ref_map elements would have _their_ commits on the new_sha1[] side,
but apparently that is not what is happening, and it has been this way for
a long time. The use of old_sha1[] came from 4191c35 (git-fetch: avoid
local fetching from alternate (again), 2007-11-11), so it is a lot more
likely that I am confused than the code is wrong and nobody noticed so
far.
What am I missing?
--
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