Jens Lehmann [off-list ref] writes:
Am 07.01.2013 02:39, schrieb Jonathan Nieder:
quoted
(just cc-ing Jens and Peter, who might be interested)
I´m currently working on teaching mv to move submodules and intend
to send those patches to the list after finishing submodule deinit.
Thanks for a heads-up.
As a couple of recent "What's cooking" message has stated, I'll
shortly kick jl/submodule-deinit topic out of 'next' back to 'pu',
so please make an update a replacement, not an incremental. If I
recall the discussion correctly, I think we agreed that deinit
should clear the slate, which means the submodule working tree
should be removed and made into an empty directory without ".git" in
it, and the last round we saw on the list didn't do that.
Thanks.
Am 07.01.2013 08:44, schrieb Junio C Hamano:
Jens Lehmann [off-list ref] writes:
quoted
Am 07.01.2013 02:39, schrieb Jonathan Nieder:
quoted
(just cc-ing Jens and Peter, who might be interested)
I´m currently working on teaching mv to move submodules and intend
to send those patches to the list after finishing submodule deinit.
Thanks for a heads-up.
As a couple of recent "What's cooking" message has stated, I'll
shortly kick jl/submodule-deinit topic out of 'next' back to 'pu',
so please make an update a replacement, not an incremental. If I
recall the discussion correctly, I think we agreed that deinit
should clear the slate, which means the submodule working tree
should be removed and made into an empty directory without ".git" in
it, and the last round we saw on the list didn't do that.
Right, and me thinks that would warrant a --force option for deinit
to do that even if the submodule contains local changes (which would
make deinit fail otherwise). Additionally Michael and Marc spoke up
that they would rather have a --all option to deinit all initialized
submodules and "git submodule deinit" without any arguments should
just produce a usage message. As I saw no voices against it that'll
be part of the next iteration too.