Heiko Voigt <hvo...@hvoigt.net> writes:
> 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.