Re: [RFC PATCH] builtin/worktree: enhance worktree removal

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Tue, Nov 21, 2017 at 10:14 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> The erroring out in this case looks like simple oversight. Most
>> likely, this particular case did not occur to Duy. The code does
>> intentionally check the directory to see if it is dirty so that it can
>> warn the user (in which case the user can re-run with --force or take
>> other corrective action), but erroring out if the directory is merely
>
> "...erroring out if the directory _is missing_ is merely..."
>
>> an indirect (and unintended) result of trying to check for dirtiness.
>>
>> So, Kaatic's patch is intended to address that oversight (though I
>> haven't examined the implementation closely; I was just trying to
>> understand the reason for the patch).

OK, so the proposed log message was a bit confusing for those who
are *not* the person who wrote it (who knew why existing behaviour
was inadequate and did not describe how "worktree remove" would fail
under such a scenario to illustrate it, incorrectly assuming that
everybody who reads the proposed log message already *knows* how it
would fail).

	"git worktree remove" removes both the named worktree
	directory and the administrative information for it after
	checking that there is no local modifications that would be
	lost (which is a handy safety measure).  It however refuses
	to work if the worktree directory is _already_ removed.

	The user could use "git worktree prune" after seeing the
	error and realizing the situation, but at that point, there
	is nothing gained by leaving only the administrative data
	behind.  Teach "git worktree remove" to go ahead and remove
	the trace of the worktree in such a case.

or soemthing like that?