Re: [PATCH] git-clean: Display more accurate delete messages

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2012, 07:04 UTC
Message-ID: <7v38zecrqc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAKJhZwROXsTa4wu-C9rhfGysetL+cZRDECyFUn5VTb833pWzMQ@mail.gmail.com>

Zoltan Klinger <zoltan.klinger@gmail.com> writes:

Show 30 quoted lines

> Would like to get some more feedback on the proposed output in case of
>  (1) an untracked subdirectory with multiple files where at least one of them
>      cannot be removed.
>  (2) reporting ignored untracked git subdirectories
>
> Suppose we have a repo like the one below:
>   test.git/
>     |-- tracked_file
>     |-- untracked_file
>     |-- untracked_foo/
>     |     |-- bar/
>     |     |     |-- bar.txt
>     |     |-- emptydir/
>     |     |-- frotz.git/
>     |     |     |-- frotx.txt
>     |     |-- quux/
>     |           |-- failedquux.txt
>     |           |-- quux.txt
>     |-- untracked_unreadable_dir/
>     |     |-- afile
>     |-- untracked_some.git/
>           |-- some.txt
>
> $ git clean -fd
> Removing untracked_file
> Removing untracked_foo/bar
> Removing untracked_foo/emptydir
> Removing untracked_foo/quux/quux.txt
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove remove untracked_unreadable_dir/

"remove remove" is a typo, I presume.

> warning: ignoring untracked git repository untracked_foo/frotz.git/
> warning: ignoring untracked git repository untracked_some.git/

If you mean "we report the topmost directory and nothing about (recursive) contents in it if everything is removed successfully" (in other words, if we had subdirectories and files inside untracked_foo/bar/ and we successfully removed all of them, the above output does not change), it seems quite reasonable.

> Use git clean --force --force to delete all untracked git repositories

But I am not sure if this is ever sane. Especially the one that removes an embedded repository is suspicious. "git clean" should not ever touch it with or without --superforce or any other command.

I do not think trying to remove something that cannot be removed due to filesystem permissions is sensible, either. We simply should treat such a case a grave error and have the user sort things out, instead of blindly attempt to "chmod" them ourselves (which may still fail).

Thanks.