Heiko Voigt <hvoigt@xxxxxxxxxx> 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.