Re: How to check new commit availability without full fetch?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 11, 2010, 19:20 UTC
Message-ID: <7vmy0kjvms.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.1001111257300.10143@xanadu.home>

Nicolas Pitre <nico@fluxnic.net> writes:

Show 22 quoted lines

> On Mon, 11 Jan 2010, Junio C Hamano wrote:
>
>> Robin Rosenberg <robin.rosenberg@dewire.com> 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?