From: Kaartic Sivaraam Date: Wed, 22 Nov 2017 17:13:44 GMT Subject: Re: [RFC PATCH] builtin/worktree: enhance worktree removal Message-ID: In-Reply-To: On Wednesday 22 November 2017 09:25 AM, Junio C Hamano wrote: > Eric Sunshine writes: >>> 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). I shouldn't have made the log message as 'ad hoc' as I made the patch, sorry :-( > > "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? > Much better!