Patrick Steinhardt [off-list ref] writes:
I think there should be a command that is able to remove those
dangling repositories if the following conditions are met:
- the submodule should not be initialized
- the submodule should not have an entry in .gitmodules in the
currently checked out revision
- the submodule should not contain any commits that are not
upstream
- the submodule should not contain other submodules that do not
meet those conditions
I do not have a strong opinion on whether it is a good idea to make
it possible to remove the .git/modules/*, but should it be a
separate subcommand, or should it be an option to the 'deinit'
subcommand?
Also, how would you apply the safety to a repository without
"upstream", i.e. the authoritative copy?
On Mon, Mar 16, 2015 at 08:55:03AM -0700, Junio C Hamano wrote:
Patrick Steinhardt [off-list ref] writes:
quoted
I think there should be a command that is able to remove those
dangling repositories if the following conditions are met:
- the submodule should not be initialized
- the submodule should not have an entry in .gitmodules in the
currently checked out revision
- the submodule should not contain any commits that are not
upstream
- the submodule should not contain other submodules that do not
meet those conditions
I do not have a strong opinion on whether it is a good idea to make
it possible to remove the .git/modules/*, but should it be a
separate subcommand, or should it be an option to the 'deinit'
subcommand?
See my response to Jonathan.
Also, how would you apply the safety to a repository without
"upstream", i.e. the authoritative copy?
Is it even possible to create a new submodule without any
upstream repository? At least `git submodule init` does not work
without a corresponding entry in .gitmodules which the user would
have needed to create himself manually. In this case one _could_
assume that the user knows what he is doing and expect him not to
call `submodule purge` (or whatever the command will be called)
on the authoritative copy. Other than that I've got no idea how
to assure safety.
Regards
Patrick
On Tue, Mar 17, 2015 at 09:18:26AM +0100, Patrick Steinhardt wrote:
Is it even possible to create a new submodule without any
upstream repository? At least `git submodule init` does not work
without a corresponding entry in .gitmodules which the user would
have needed to create himself manually. In this case one _could_
assume that the user knows what he is doing and expect him not to
call `submodule purge` (or whatever the command will be called)
on the authoritative copy. Other than that I've got no idea how
to assure safety.
Look at git/t/t7400-submodule-basic.sh for example at the test starting
at line 84 on how to add a submodule without any upstream.
Git has already a disadvantage against other SCM (like mercurial)
because it's "too easy to loose data with git". Meaning that we purge
unrefered commits. (Yes this is up to debate if this is good or bad, but
here's not the place).
I think we should be very carefully with adding commands that
permanently removes data. They should be really well crafted so that
there's no way to do this by mistake.
--
Fredrik Gustafsson
phone: +46 733-608274
e-mail: iveqy@iveqy.com
website: http://www.iveqy.com