Confusing `hg add` + `hg remove` behavior
gregory.szorc at gmail.com
Fri Sep 2 12:24:00 EDT 2016
> 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:
>> 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
> 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 :/
More information about the Mercurial-devel