Re: submodule update --force

Hi,

On Mon, May 14, 2012 at 10:17:53AM -0700, Stefan Zager wrote:

On Mon, May 14, 2012 at 9:52 AM, Heiko Voigt [off-list ref] wrote:

quoted

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.

quoted

(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.

For this use case running

	git submodule update -f

is just fine. The only objection I had was against a new option. So I am
all for making -f skip this sha1 comparing optimization like your patch
did.

On a side note: I am surprised that cloning through git is really that
much slower than copying a zip from the network. Do you run git gc
regularly enough on the server?

Cheers Heiko