Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)

On 5/28/08, Junio C Hamano [off-list ref] 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