Shawn Bohrer wrote: > 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/ > 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. -- 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
