From: Junio C Hamano <gitster@pobox.com>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: git@vger.kernel.org, "Michał Górny" <mgorny@gentoo.org>,
"Phil Hord" <phil.hord@gmail.com>,
"Heiko Voigt" <hvoigt@hvoigt.net>
Subject: Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
Date: Mon, 09 Jul 2012 12:38:22 -0700 [thread overview]
Message-ID: <7vpq84k9n5.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4FFB23EB.8060409@web.de> (Jens Lehmann's message of "Mon, 09 Jul 2012 20:33:15 +0200")
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Cool, so let's drop this patch and I'll teach "rm" to handle
> populated submodules according to what we do for regular files:
> Make sure there are no modifications which could get lost (unless
> "-f") and remove all tracked files and the gitfile from the work
> tree (unless "--cached") before removing the submodule from the
> index. If the submodule uses the old layout with the .git
> directory instead of a gitfile we error out just like we do today.
Alternatively we could "mv" .git directory out of the way and the
next "git checkout" of a branch that still has the submodule can
make a gitfile to point there, no?
Or we can just error out and tell the user to do so herself.
> And we didn't talk about untracked or ignored files which may live
> inside the submodules work tree so far, but according to what a
> "rm -r" does in the superproject they should still be around after
> using "rm" on a populated submodule, right?
Until we add the "precious" class, untracked and ignored files are
expendable, so if a submodule working tree has no modification and
only has leftover *.o files, they can be nuked as part of submodule
removal, but if it has an untracked and unignored *.c file for
example, the "rm" operation without "-f" should be stopped, no?
next prev parent reply other threads:[~2012-07-09 19:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 20:43 [RFC PATCH 0/2] Teach rm to better handle submodules Jens Lehmann
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 [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vpq84k9n5.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).