[RFC PATCH 0/2] Teach rm to better handle submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a follow-up to gmane thread 200564 about teaching "git
submodule" the "rm" command. It has the intention to only having
to add a small amount of new code to the submodule script while
handling the heavy lifting in core git.

With this series I also intend to make submodule handling a bit
easier for users by teaching "git rm" to remove the submodule
section from the .gitmodules file, no matter if the submodule is
populated or not. Not being able to do that because the section
is not found there or the .gitmodules file is already deleted
will only issue a warning (with the intent to make the user aware
that "git rm" would do that for him in case he did that himself).

The first patch introduces a change in behavior: Using rm on a
populated submodule will not error out anymore but just issue a
warning instead (In a subsequent series I intend to teach rm the
--recurse-submodule option to really remove the submodule when
its .git is a gitfile. Then the usual checks for a submodule to
not accidentally loose any changes will be added, for now it just
compares the submodules HEAD to the commit recorded in the index).
Me thinks this change should be ok as it makes a former failing
call succeed, but maybe others disagree here.

The second patch removes the corresponding submodule section from
.gitmodules, which should be done when removing a submodule so it
can be done by git itself to help the user ("git submodule add"
automatically adds it, so "git [submodule] rm" should also remove
it).

This series adds some extra cost to a "git rm" because of the
parsing of the .gitmodules file and keeping track of which of the
to-be-deleted entries are submodules, but I don't expect that to
be noticeable. Parsing .gitmodules is needed in the long run
anyways to detect submodules whose work tree is configured to be
removed automatically (or not) and the extra 'is_submodule' flag
is only added for the files to be removed and setting and testing
it is fast.

I would appreciate if someone with more knowledge of the index
api than I have to review the stage_updated_gitmodules() in patch
2 to see if I'm doing something stupid there.

Opinions?


Jens Lehmann (2):
  rm: don't fail when removing populated submodules
  rm: remove submodules from the index and the .gitmodules file

 builtin/rm.c         | 42 +++++++++++++++++---------
 submodule.c          | 55 ++++++++++++++++++++++++++++++++++
 submodule.h          |  2 ++
 t/t3600-rm.sh        | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 t/t7610-mergetool.sh |  6 ++--
 5 files changed, 172 insertions(+), 17 deletions(-)

-- 
1.7.11.1.105.g9f6831b

--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]