Re: [PATCH 2/2] serialize collection of refs that contain submodule changes

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 19, 2016, 20:09 UTC
Message-ID: <xmqqeg4fejne.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160919195118.GB62429@book.hvoigt.net>

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 6 quoted lines

> I am not sure if I understand you correctly here. With the "ref cache layer"
> you are referring to add_submodule_odb() which is called indirectly from
> submodule_needs_pushing()? Those revs are only used to check whether the hash
> we need on the remote side exists in the local submodule. That should not
> change due to a push. The actual check whether the commit(s) exist on the
> remote side is done using a 'rev-list' in a subprocess later.

I was wondering what would happen in this scenario:

 * You have ON_DEMAND set, which causes "git -C sub push origin" to
   push out what are new, updating the remote tracking branches in
   the submodule, sub/.git/refs/remotes/origin/*.

 * Then you check again.  If you used for-each-ref-in-submodule, the
   updated refs/remotes/origin/* may not have been re-read.

But you check by spawning "rev-list ... --not --remotes" as a separate process in submodule_needs_pushing(), and that will force the new process to read the updated state, so it turns out that I was overly worried without good reason ;-)

It may matter once somebody tries to internalize the external rev-list call done via start_command() interface to an internal call, though. But we are not there yet.