Re: submodule update --force

From: Stefan Zager <szager@google.com>
Date: May 14, 2012, 17:17 UTC
Message-ID: <CAHOQ7J_O=8NL0wp0Pu6pfjN_Y6NDJhKZUft9G2FL0vUWL7aEBw@mail.gmail.com>
In-Reply-To: <20120514165231.GB58058@book.hvoigt.net>

On Mon, May 14, 2012 at 9:52 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:

Show 18 quoted lines

> Yes we should eliminate surprises thats true. On the other hand there is
> no way to setup submodules in the way Stefan had them by using the git
> submodule command or is there? So for his use case the command sequence
> you described seems to be more appropriate but I am not sure whether
> that justifies a separate option for it.
>
>> (3) is too heavy when I really only wanted (2).
>>
>> I do not understand that use case that led Stefan to the predicament
>> he was in where he had submodules with HEADs but with no checked out
>> files.  But I do not begrudge his being there.
>
> Yes, but currently -f is wrong in the way that when the submodules HEAD
> sha1 is the same as registered in the superproject it will skip the
> checkout. That is wrong when you have local uncommitted changes in the
> worktree. In such a state I would expect it to throw away those local
> changes and checkout HEAD. So I think Stefans patch makes sense anyway
> even though it might actually be to heavy for his use case.

To satisfy your curiosity, although it probably won't help me make my case: I'm working on very large project with a lot of commit history. Cloning this repository is prohibitively slow, so I'm trying to speed it up by periodically creating a snapshot of the repository (and all submodule repositories) that can be downloaded and cloned locally.

I first tried using `git bundle`, but cloning from the bundle files was still very slow, because it took a long time to replay all the commit history to recreate the index. So, I hit upon another solution: run `git clone -n` on the top-level repository and all submodule repositories, and create a zip file of the empty checkout. The resulting zip file is the same size as the git bundle file, but unpacking it on the client (basically, `unzip` followed by `git checkout HEAD`) is much faster.

Stefan