Re: [PATCH] submodule update - don't run git-fetch if sha1 available

From: Torgil Svensson <torgil.svensson@gmail.com>
Date: Aug 12, 2007, 00:03 UTC
Message-ID: <e7bda7770708111703u40f89c1fx17bfac4b9aed9d2e@mail.gmail.com>
In-Reply-To: <7vfy2pn9eb.fsf@assigned-by-dhcp.cox.net>

On 8/11/07, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> 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