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 <hvoigt@xxxxxxxxxx> wrote: > > > 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. 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 -- 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