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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Zoltan Klinger <zoltan.klinger@xxxxxxxxx> writes:

> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]