On Wed, Feb 7, 2018 at 3:08 AM, Duy Nguyen <pclo...@gmail.com> wrote: > On Wed, Feb 7, 2018 at 7:00 AM, Elijah Newren <new...@gmail.com> wrote: >> and knew they had been using it, then I might have guessed that "HEAD" >> meant "not your actual HEAD but the HEAD of the vestige of some other >> worktree"). >> >> Does anyone have pointers about what might be doable in terms of >> providing a more useful error message to allow users to recover? > > I noticed this too. I was working on improving this message a bit but > got side tracked and since I figured this did not happen often > anymore, this fix got lower priority than others. I'll resume that > work.
Sweet, that'd be great. Let me know if I can help. >> And/or ideas of what steps could cause corruption so I can send out a >> PSA to help users avoid it? > > There is another thing we could do. One bad HEAD should not abort the > entire operation (at least if it's not the current worktree's HEAD). > We could still give a warning and move on, or don't warn at all and > let "git worktree prune" collect it (which I see from your message > that it also fails to do). > > I guess that's two more items on my todo list :) Cool, if you're taking a look at those, I'll take a look at the other one mentioned by Peff in this thread -- "make fsck pay attention to other worktree HEADs" :-) > Sorry for all the trouble because of this bug of mine. Let me apologize if my tone came across too harshly in the report; I sometimes accidentally do that. Anyway, bugs happen. People were able to get back up and running with "just reclone somewhere else" pretty quickly, and no one lost any important data here, it was just jarring or perplexing enough that I felt the need to dig and figure out an improvement before more reports come in. Besides, you've made git a lot better. Thanks for that.
