From: Torgil Svensson <torgil.svensson@gmail.com>
Date: Sun, 12 Aug 2007 00:03:17 GMT
Subject: Re: [PATCH] submodule update - don't run git-fetch if sha1 available
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:

> 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