Confusing `hg add` + `hg remove` behavior

[Gregory Szorc]

> On Sep 2, 2016, at 03:01, Simon King <simon at simonking.org.uk> wrote:
> 
>> On Fri, Sep 2, 2016 at 1:54 AM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
>> One of my coworkers just blogged about confusing behavior w.r.t. performing
>> a `hg remove` on a file that was `hg add`ed but not yet committed:
>> http://code.v.igoro.us/posts/2016/09/user-guidance-vs-dwim.html
>> 
>> Is there room to change the behavior of `hg remove` to behave more like `hg
>> forget` in this scenario? Or is the best we can do a wording change?
> 
> If it were to change, what do you think it should do? "hg rm" deletes
> from the working copy whereas "hg forget" doesn't. By saying that rm
> should behave more like forget, are you suggesting that in the
> specific case of a file having been added but not committed, "hg rm"
> no longer deletes from the working copy? That sounds pretty nasty to
> me.
> 
> The current behaviour is trying to prevent data loss by refusing to
> delete a file which has never been committed. Maybe the error message
> could say something like:
> 
> (use "hg rm -f" to delete the file from your working copy, or "hg
> forget" to stop tracking it without deleting it)
> 
> ...although that's still a bit long. Giving the 2 alternatives makes
> it clearer why hg hasn't just DWIM.

Yea, I was suggesting that 'hg remove' on a file that has been added but not committed will remove the tracking but retain the file on disk. That preserves symmetry between add/remove without incurring data loss. Although, it makes the behavior of 'hg remove' inconsistent depending on commit state. Lesser of 2 evils might be the backwards compatible behavior :/