On 5/28/08, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Please learn to think before typing, let alone sending such a message to > waste other people's time. Phew, just mentioning Windows on this list seems to get people flamed. Reading over my message, I'm not sure what I would have written to have it interpreted as being negative. I was simply suggesting that git could fail more gracefully here. > We give the user an error message, and signal error by exiting with > non-zero. You cannot have that path on the system, and we are being > honest about it. It is not like we are suddenly painting the screen in > blue and refusing to get any more user input when you try to check out > such a tree. Which part of that is _not_ surviving? The part that's not surviving is git-bisect, which is a valid problem that resulted in someone asking to rewrite the history. Clearly rewriting the history is not a good solution, thus no good solution has yet been proposed, which is why I wrote my message. > The system with a *fatal* error is not git but the one that does not want > an not-so-unreasonable name "NUL" on it. That is clearly true. But knowing that doesn't seem to be making this user's problem go away. > What alternatives do you want to implement? Certainly not silently > creating "nul-garbage" file instead and pretend that nothing bad happened, > as that would lead to madness. If the file failed to be created (with a warning), but we treated it as having been deleted in 'git status' instead of throwing an error, it would work much like the case sensitivity problem: the index is annoyingly dirty, but you can still get work done. I think that (perhaps with a little patch) would allow git-bisect to work. Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
