[PATCH] update: do not remove cwd

[Stanislau Hlebik]

Makes sense. But Durham's idea about warning seems legit. When i ran into this problem when doing 'hg split', i spent a few minutes figuring out where the problem came from. If i had warning like 'your cwd was deleted; if it causes problems go to the root' i'd found the solution sooner.



Sent from Samsung Mobile on O2


-------- Original message --------
From: Matt Mackall <mpm at selenic.com>
Date: 30/08/2016 20:23 (GMT+00:00)
To: Stanislau Hlebik <stash at fb.com>, mercurial-devel at mercurial-scm.org
Subject: Re: [PATCH] update: do not remove cwd

On Mon, 2016-08-29 at 11:50 -0700, Stanislau Hlebik wrote:
> # HG changeset patch
> # User Stanislau Hlebik <stash at fb.com>
> # Date 1472496038 25200
> #      Mon Aug 29 11:40:38 2016 -0700
> # Node ID e1962781ce84040746ef79c0084b8fd70cfcd4b4
> # Parent  318e2b600b80e4ed3c6f37df46ec7544f60d4c0b
> update: do not remove cwd
>
> During update directories are deleted as soon as they have no entries.
> But current working directory shouldn't be deleted because it
> causes problems for users after hg finishes.

It is a perfectly valid state that POSIX allows. So we shouldn't make those
problems our problems.

>  Also it makes complex commands
> like 'hg split' fail.

Those failures are also arguably bugs in their own right.

But this approach introduces new complexities. For instance, what happens if the
current directory gets replaced by a symlink? Whether that works depends on
where you run the command. And how does the not-deleted directory get cleaned up
so as not to interfere with future operations?

If we wanted to disallow this, we'd ideally abort early so the user could run
the operation in a sane location. But that's not generally easy to discover. And
aborting later is likely to make a mess.

(Alternate idea: rename the current directory to .oh-no-you-ran-an-hg-command-
that-deleted-your-current-directory-please-clean-up-your-mess-kthxbye.)

--
Mathematics is the supreme nostalgia of our time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160830/f17eae5b/attachment.html>