Problems with the "purge" command

[Steve Fink]

At least with my version of hg (6.2.2), using the built-in purge command
with --no-confirm works. As does putting

[defaults]
purge = --no-confirm


On Sat, Jun 17, 2023 at 2:24 AM Dr Rainer Woitok <rainer.woitok at gmail.com>
wrote:

> Craig,
>
> On Friday, 2023-06-16 10:07:22 -0600, you wrote:
>
> > On Fri, Jun 16, 2023 at 9:54 AM John W <jwdevel at gmail.com> wrote:
> >
> > > I find that putting "hgext.purge =" in my [extensions] makes the
> > > difference.
> > > ...
> >
> > This is currently the only way to get purge to not query. When purge was
> > moved to core, the default behavior was changed to always
> > query the user.
>
> In my world any discrepancy between some piece of code  and its documen-
> tation clearly is a bug.  Either in the code or in the documentation.
>
> Besides,  my experience has taught me  that having code  ask back before
> doing something irreversibly destructive  as in the classical suggestion
> of having "alias rm=rm -i" is futile due to human psychology:  after us-
> ing such a command for a while  and getting used to typing "y" and hitt-
> ing "ENTER" after each invocation, you will eventually do that automati-
> cally,  and will only  realize your glitch  after the fact,  just as you
> would without being asked back :-/
>
> So for the case at hand I'm clearly voting for having the code implement
> what the documentation describes, and for the time being I humbly revert
> to the good ol' solution of using "!$HG status -nu0  |  xargs -0 rm -f",
> which -- by the way -- is still advertised in "man 5 hgrc".
>
> Sincerely,
>   Rainer
> _______________________________________________
> Mercurial mailing list
> Mercurial at lists.mercurial-scm.org
> https://lists.mercurial-scm.org/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20230617/03d1249f/attachment.html>