Re: [PATCH] git clean: Don't automatically remove directories when run within subdirectory

From: Joachim Berdal Haga <cjbhaga@broadpark.no>
Date: Apr 15, 2008, 06:33 UTC
Message-ID: <48044C33.20006@broadpark.no>
In-Reply-To: <20080415034417.GA2882@lintop>

Shawn Bohrer wrote:

Show 9 quoted lines

> On Mon, Apr 14, 2008 at 08:18:13PM +0200, Joachim Berdal Haga wrote:
>> I think that the best option would be to never remove a directory, even if
>> given explicitly, unless -d is given. Because my gut feeling is that when a
>> directory name is specified, it is most often meant as "clean inside the
>> given directory", ie. as a path delimiter.
> 
> If there are no tracked files the only difference between the dir/ and
> dir case is that the former will leave behind an empty directory.  So
> the difference between too much and too little is of little importance.

No, check this out; note that only in the very last case dir/subdir/subfile would be removed.

$ git init; mkdir -p dir/subdir; touch dir/file dir/subdir/subfile Initialized empty Git repository in .git/ $ touch dir/tracked-file; git add dir/tracked-file $ ~/src/git/git-clean -n dir/ Would remove dir/file Would not remove dir/subdir/ $ ~/src/git/git-clean -n dir Would remove dir/file Would not remove dir/subdir/ $ git rm -f dir/tracked-file rm 'dir/tracked-file' $ ~/src/git/git-clean -n dir/ Would remove dir/file Would not remove dir/subdir/ $ ~/src/git/git-clean -n dir Would remove dir/

Show 6 quoted lines

> However,
> 
> git clean dir
> Would not remove dir/
> 
> is a little strange.

Yes, although it could be made less strange by adding a short explanation, like "Would not remove dir/ (-d not given)". But I also think that the difference between "dir" and "dir/" is very (too?) subtle in this case and therefore should require explicit approval/action from the user.

-j.