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

On Wed, 28 May 2008, Junio C Hamano wrote:

"Avery Pennarun" [off-list ref] writes:

quoted

As an unhappy Windows user myself (sometimes), I think it might be
better to simply fix git to *survive* failing to create files like
'nul' on Win32, rather than trying to *fix* such files in the repo.
It sounds (from the original post) like git has a *fatal* error
("cannot be checked out on cygwin") when trying to create 'nul'.

Please learn to think before typing, let alone sending such a message to
waste other people's time.

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 system with a *fatal* error is not git but the one that does not want
an not-so-unreasonable name "NUL" on it.  Git survives on such a system
and tells you what happened --- you cannot do certain things, such as
checking out such a tree.  You live with it, or get a better system ;-)

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.

Report a non-fatal error, mark in the index that that entry is not 
reflected in the working directory, and allow the user to manipulate it 
with commands that don't really need the working directory content.

$ git checkout origin/master
Warning: couldn't create 't/t5100/nul' in your working directory; ignoring 
working directory for this filename.
$ git mv t/t5100/nul t/t5100/nul-plain
$ ls t/t5100/nul-plain
t/t5100/nul-plain

The working directory doesn't really have to be absolutely vital to git's 
functioning (of course, the project you've checked out is going to have 
problems unless you fix things). In particular, it should be possible, on 
a machine with a broken filesystem, to modify a project that triggers the 
filesystem breakage to not trigger it, rather than having to rely on 
either read-tree/update-index --cachinfo/write-tree or a helpful user of a 
non-broken system to get things working again.

Git should, I think, even be able to figure out by itself when to not 
trust the filesystem; if open gives EEXIST, but readdir doesn't list it, 
it's a filesystem problem and we should work around it.

	-Daniel
*This .sig left intentionally blank*