"Torgil Svensson" [off-list ref] writes:
It's un-necessary (both time-consuming and annoying if you are
disconnected) for git submodule update to always running git-fetch
prior to the detached head checkout of the submodule if the commit
already exists.
This is wrong. Existence of the commit object alone does not
mean the necessary tree and blob objects to check out that
commit, let alone all the history that leads to the commit,
exist in the repository (think of a commit walker fetch that was
interrupted in the middle). You need to make sure that the
commit exists *AND* is reachable from one of the refs.
On 8/11/07, Junio C Hamano [off-list ref] wrote:
This is wrong. Existence of the commit object alone does not
mean the necessary tree and blob objects to check out that
commit, let alone all the history that leads to the commit,
exist in the repository (think of a commit walker fetch that was
interrupted in the middle). You need to make sure that the
commit exists *AND* is reachable from one of the refs.
That made sense. Good point. Consider this case:
$ git clone <superproject>
$ git submodule init
$ git submodule update
$ cd <submodule>
$ git checkout master
$ cd ..
$ git status
Modified <submodule>
$ git submodule update
Do we know in this state that the ref can be reached from a reference?
Say you've managed to do this:
$ cd <submodule>
$ git checkout master
$ work.. commit .. work ..commit
$ cd ..
$ git add <submodule>
$ git commit
$ cd <submodule>
$ git reset --hard HEAD~2
Is it okay to fail the supermodule update in this state? Obviously
we've thrown away things for a purpose.
//Torgil