On Wednesday 22 November 2017 09:25 AM, Junio C Hamano wrote:
Eric Sunshine <sunsh...@sunshineco.com> 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!
