From: Jens Lehmann <Jens.Lehmann@web.de>
To: git@vger.kernel.org
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Michał Górny" <mgorny@gentoo.org>,
"Phil Hord" <phil.hord@gmail.com>,
"Heiko Voigt" <hvoigt@hvoigt.net>
Subject: [RFC PATCH 0/2] Teach rm to better handle submodules
Date: Wed, 04 Jul 2012 22:43:19 +0200 [thread overview]
Message-ID: <4FF4AAE7.40604@web.de> (raw)
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
next reply other threads:[~2012-07-04 20:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 20:43 Jens Lehmann [this message]
2012-07-04 20:44 ` [RFC PATCH 1/2] rm: don't fail when removing populated submodules Jens Lehmann
2012-07-06 6:57 ` Junio C Hamano
2012-07-07 12:51 ` Jens Lehmann
2012-07-08 7:32 ` Junio C Hamano
2012-07-08 15:08 ` Jens Lehmann
2012-07-09 2:17 ` Junio C Hamano
2012-07-09 5:02 ` Junio C Hamano
2012-07-09 18:33 ` Jens Lehmann
2012-07-09 19:38 ` Junio C Hamano
2012-07-09 20:23 ` Jens Lehmann
2012-08-16 21:56 ` Junio C Hamano
2012-08-17 16:44 ` Jens Lehmann
2012-08-17 18:11 ` Phil Hord
2012-08-19 19:38 ` Jens Lehmann
2012-07-04 20:44 ` [RFC PATCH 2/2] rm: remove submodules from the index and the .gitmodules file Jens Lehmann
2012-07-05 0:44 ` [RFC PATCH 0/2] Teach rm to better handle submodules Junio C Hamano
2012-07-05 19:06 ` Jens Lehmann
2012-07-05 22:10 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FF4AAE7.40604@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hvoigt@hvoigt.net \
--cc=mgorny@gentoo.org \
--cc=phil.hord@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).