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