On Thu, Apr 18, 2013 at 1:02 AM, Ramkumar Ramachandra
>> No, the point is people make mistakes. What do we do in that case? Or
>> will you introduce yet another "gc" command for clean up ~/bare?
> So, people don't make mistakes when they use 'git submodule add', but
> do make mistakes when using 'git clone'? How has the problem
> _changed_ with my patch? It's reasonable to point it out as an
> existing problem, and ask for it to be fixed independent of this
> discussion, but that is not what you are doing.
It's the magic in git-clone that changes its behavior that I want to
address. I know you agree to go with a command line option. But I
think in the end there will be a switch hidden somewhere in config to
make things smooth, unless you make this mode the default (*). With
normal mode, "rm -rf repo" is enough, with the new submodule mode, it
leaves some garbage behind that the user may not be aware about. Maybe
this is something that should be addressed anyway even for .gitmodules
mode like Junio said. But I wonder if there are any other traps that
come with the config switch.
(*) I don't think you can make the new mode the default though. There
are repos in repos in the field that are not managed by "git
submodule". Switching the default will disrupt those setups. Some
deprecation cycles might help, I don't know.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html