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

From: Joachim Berdal Haga <cjbhaga@broadpark.no>
Date: Apr 14, 2008, 18:18 UTC
Message-ID: <48039FE5.5060309@broadpark.no>
In-Reply-To: <20080414170643.GA10548@mediacenter>

Shawn Bohrer wrote:

Show 5 quoted lines

> Agreed I'll send an updated patch later tonight.  One additional thought
> though.  2 is MATCHED_FNMATCH which worries me a little because I think
> this would mean 'git clean -f *' will also remove directories (I haven't
> tried though).  Perhaps this should really be 3 MATCHED_EXACTLY just to
> be safe.  Does anyone have opinions either way?

I don't have strong opinions on this since I don't use this form of the command, but still:

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).

-j.