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

Ben Kehoe benk at berkeley.edu
Mon Nov 18 15:44:54 CST 2013


On Sat, Nov 16, 2013 at 5:09 PM, Kevin Bullock <
kbullock+mercurial at ringworld.org> wrote:

> On 16 Nov 2013, at 4:03 PM, Ben Kehoe <benk at berkeley.edu> wrote:
>
> > On Sat, Nov 16, 2013 at 12:54 PM, Kevin Bullock <
> kbullock+mercurial 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 :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20131118/330c1500/attachment.html>


More information about the Mercurial-devel mailing list