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

[Junio C Hamano <gitster@pobox.com>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Ah, yes, CE_VALID. But it doesn't quite work as well as I'd like, because 

No, I do not think we should involve CE_VALID here.  It means something
completely different.  What I meant was that through "git status" the user
can tell there is an unexpected breakage in the work tree, _if_ we make
checkout to finish with "best effort" (and still report an error).

> I think the right test for this is if create_file() returns EEXIST, but 
> readdir doesn't show anything.

I think relying on EEXIST is too specific for this particular breakage,
even though such a test may catch it.  A checkout may fail in the middle
if a filesystem refuses to create a pathname that has certain characters
in it (e.g. dosen't NTFS refuse a path with :|<"?*> in it, or is it just
the Explorer UI layer rejecting them?), or perhaps one leading directory
may be unwritable.  We would want to catch and cope with such a brokage
the same way.

The checkout "unpack-trees" codepath does:

 - Make sure things can be checked out safely with the internal data
   before doing anything to the filesystem, i.e. no lost local changes, no
   lost untracked files, etc.

 - For each path:

   - make room for it, removing directory at the place as necessary where
     a blob must sit and removing an existing blob as needed;

   - create a new file or symlink;

And currently I think we stop on any failure.  The thing is, stopping on a
failure during the internal checking is fine --- no external damage has
been made yet.  But once we started updating the work tree, we _are_
committed and not aborting in the middle for a single failure would be the
saner thing to do.  In addition, even after such a failure after we are
committed, we probably should update the HEAD and the index.

"status" would then show the difference between what should have been
checked out and what is.  It might be enough to improve the issue of "git
bisect hitting a checkout failure --- the work tree is half checked-out
state, and the index, the HEAD, and the work tree are in a very
inconsistent state".

We would probably signal such an error from git-checkout differently from
an early refusal that does not do anything, to tell the callers, such as
"git-bisect", that the checkout _has been_ already done, even though there
may be breakages in the work tree.

> ... that notes the situation where you seem to have file A instead of 
> file B, but fstat("B") returns A's inode, and marks the index to say that 
> entry B is listed in the filesystem as A instead.

I personally do not think such auto-substution is a way to go --- what
makes you trust inode information from such an untrustworthy filesystem
that does not do what it was told to do?  I suspect that stopping at the
error site and not automatically making the damage yet larger by doing
such magic would keep the recovery procedure simpler.

But I wouldn't keep people from experimenting.  Perhaps the end result
could be even readable and mergeable, although I am quite pessimistic.