On 8/11/07, Junio C Hamano <gitster@xxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
