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. Indeed, if the directory has > tracked files inside of it, > git clean dir > and > git clean dir/ > have the same effect. If there are no tracked files inside, the current > patch gives the path-delimiting effect on this form > git clean dir/ > but removes the whole directory irrespective of "-d" for this form > git clean dir > I think that a "honor (lack of) -d even if pathspec matches" would reduce > the consequences of this particular kind of user error (by deleting too > little instead of too much). 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. However, git clean dir Would not remove dir/ is a little strange. -- Shawn -- 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
