[PATCH] purge: add options for deleting only files or only directories

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sun Apr 13 23:05:59 CDT 2014


This discussion seems to have never been concluded?

Shall we consider the feature rejected?

On 11/18/2013 04:44 PM, Ben Kehoe wrote:
> On Sat, Nov 16, 2013 at 5:09 PM, Kevin Bullock
> <kbullock+mercurial at ringworld.org
> <mailto:kbullock+mercurial at ringworld.org>> wrote:
>
>     On 16 Nov 2013, at 4:03 PM, Ben Kehoe <benk at berkeley.edu
>     <mailto:benk at berkeley.edu>> wrote:
>
>      > On Sat, Nov 16, 2013 at 12:54 PM, Kevin Bullock
>     <kbullock+mercurial at ringworld.org
>     <mailto:kbullock%2Bmercurial at ringworld.org>> wrote:
>      >
>      >> I agree with Matt, I think for the user-facing portion of this
>     it doesn't make much sense to add options when we have a mechanism
>     for specifying arbitrary groups of files. I'm not sure how useful it
>     will be outside purge to specify just regular files or just
>     directories, but I _can_ see a use case for e.g. specifying all
>     executable files.
>      >>
>      > Maybe I don't understand filesets well enough, but what are the
>     filesets that would indicate "all directories" and "all files (but
>     not directories)"?
>
>     I think we're suggesting you implement them. :)
>
> Ah, I see. I don't mean to be petulant, but it seems to me like filesets
> may not be the right solution. The semantics of the existing positional
> arguments to purge expect a directory to be given and take this to mean
> "all files and subdirectories within this directory", so to be
> consistent, giving a fileset that only matched directories would still
> not produce the effect of "delete only empty directories, not untracked
> files".
> As a user, when I first encountered the purge extension, it was apparent
> that it did two separate (though related) things: delete untracked
> files, and delete empty directories. It seems to me like simply allowing
> these two functions to be performed individually should be more
> appealing than adding new semantics to filesets that are only relevant
> for an extension.
> I could of course be totally missing the point here, in which case,
> please enlighten me :-)
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>


More information about the Mercurial-devel mailing list