Yes, this was the intent of this fix last month On Friday 18 March 2011 15:01, Junio C Hamano wrote: > Carl FÃrstenberg <azatoth@xxxxxxxxx> writes: > > Sorry for re-posting the question but I though I should explain the > > issue better and to fix the subject line. > > sub > > When you are cloning repository containing submodules, and you are > > using the --merge flag to "git submodule update" the first time, then > > the submodule instance in question will assume you want to delete all > > files present in the module. > > Is this something we fixed last month? > > commit 1b4735d9f3e0b7ea62c7c22f0afcb45e10c46c7e > Author: Spencer E. Olson <olsonse@xxxxxxxxx> > Date: Thu Feb 17 09:18:45 2011 -0700 > > submodule: no [--merge|--rebase] when newly cloned > > "git submodule update" can be run with either the "--merge" or > "--rebase" option, or submodule.<name>.update configuration variable can be > set to "merge" or "rebase, to cause local work to get integrated when > updating the submodule. > > When a submodule is newly cloned, however, it does not have a check out > when a rebase or merge is attempted, leading to a failure. For newly > cloned submodules, simply check out the appropriate revision. There is > no local work to integrate with for them. > > Signed-off-by: Spencer E. Olson <olsonse@xxxxxxxxx> > Acked-by: Jens Lehmann <Jens.Lehmann@xxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> -- 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