Re: [PATCH] Add git-clean command

From: Junio C Hamano <junkio@cox.net>
Date: Apr 4, 2006, 00:06 UTC
Message-ID: <7vzmj2b3w3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060403221841.25097.18242.stgit@dv.roinet.com>

Pavel Roskin <proski@gnu.org> writes:

> This command removes untracked files from the working tree.  This
> implementation is based on cg-clean with some simplifications.  The
> documentation is included.

I am not opposed to the command in the sense that I do not want to forbid people from doing what they want to do, but on the other hand I do not see why people (apparently many people) want to have something like this. Are their "make clean" broken?

Having said that, just some nitpicks.

> diff --git a/.gitignore b/.gitignore
>...
> +git-clean

I appreciate the attention to the detail; very nice to have a .gitignore entry along with addition of a command.

> diff --git a/git-clean.sh b/git-clean.sh
>...
> +for arg in "$@"; do

	for arg
        do
        	...

> +	if [ "$arg" = "-d" ]; then

	case "$arg" in -d)...

Show 12 quoted lines

> +excl1=
> +excl2=
> +if [ -z "$noexclude" ]; then
> +	excl1="--exclude-per-directory=.gitignore"
> +	if [ -f "$GIT_DIR/info/exclude" ]; then
> +		excl2="--exclude-from=$GIT_DIR/info/exclude"
> +	fi
> +fi
> +
> +git-ls-files --others --directory "$excl1" "$excl2" |
> +while read -r file; do
> ...

The $noexclude case passes two empty strings to git-ls-files, which may happen to be harmless with the current implementation, but does not feel quite right.

Maybe better to read ls-files -z to be really pathname safe, I dunno.

> +		$echo1 "Removing $file"
> +		[ "$cleandirhard" ] && chmod -R 700 "$file"

I am not quite sure this chmod -R is a good idea. If we are trying really hard would we need to also make sure we can rmdir the "$file" by chmod'ing its parent directory? But once we start doing that where would we stop?