Am 17.08.2012 20:11, schrieb Phil Hord:
> On Fri, Aug 17, 2012 at 12:44 PM, Jens Lehmann 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.
On Fri, Aug 17, 2012 at 12:44 PM, Jens Lehmann 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 command for
Am 16.08.2012 23:56, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Am 09.07.2012 21:38, schrieb Junio C Hamano:
>>> Jens Lehmann 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
Jens Lehmann writes:
> Am 09.07.2012 21:38, schrieb Junio C Hamano:
>> Jens Lehmann 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 (unle
Am 09.07.2012 21:38, schrieb Junio C Hamano:
> Jens Lehmann 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 tra
Jens Lehmann 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 (unle
Am 09.07.2012 04:17, schrieb Junio C Hamano:
> Jens Lehmann 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 think it i
Junio C Hamano 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,
>> merge, p
Jens Lehmann 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
>> abov
Am 08.07.2012 09:32, schrieb Junio C Hamano:
> Jens Lehmann 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/.g
Jens Lehmann 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 if
Am 06.07.2012 08:57, schrieb Junio C Hamano:
> Jens Lehmann 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" errors
> ou
12 matches
Mail list logo
