Am 17.08.2012 20:11, schrieb Phil Hord:
On Fri, Aug 17, 2012 at 12:44 PM, Jens Lehmann jens.lehm...@web.de wrote:
I'm almost there. The only thing left is to check if a nested
submodule is using a git directory. In that case I expect rm to
fail even when -f is used to protect the submodule's
Am 16.08.2012 23:56, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
Am 09.07.2012 21:38, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@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
On Fri, Aug 17, 2012 at 12:44 PM, Jens Lehmann jens.lehm...@web.de wrote:
I'm almost there. The only thing left is to check if a nested
submodule is using a git directory. In that case I expect rm to
fail even when -f is used to protect the submodule's history. I
still need to find a suitable
Am 09.07.2012 04:17, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
So I still think --recurse-submodules does not make any sense to
the rm command. I would understand a Do not attempt to remove
submodules and ignore their existence altogether option, even
though I do not
Jens Lehmann jens.lehm...@web.de writes:
One possible sane behaviour of git rm $path might be:
- If --force is given, remove it from the index and from the
working tree (i.e. rm -rf $path), but use the gitfile
facility to save $path/.git away to $GIT_DIR/modules/$name; error
out
Am 08.07.2012 09:32, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
One possible sane behaviour of git rm $path might be:
- If --force is given, remove it from the index and from the
working tree (i.e. rm -rf $path), but use the gitfile
facility to save $path/.git
Jens Lehmann jens.lehm...@web.de writes:
What you describe here is exactly how I think git submodule rm and
git rm --recurse-submodules should behave.
If you have a directory A with a file B in it (i.e. A/B), git rm A
is refused and you have to say git rm -r A. So I can see why the
above
Junio C Hamano gits...@pobox.com writes:
Nope. Only the --recursive option to the git submodule script
works like that (and almost everyone seems to use that option by
default anyway). But for all commands that understand the
--recurse-submodule option (currently these are clone, fetch,
Am 06.07.2012 08:57, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
Also apply the same policy as for regular files and
require forcing when the submodules HEAD is different than what is
recorded in the index.
I think the policy for regular files is that git rm $path
9 matches
Mail list logo
