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