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

Daniel Barkalow <barkalow@iabervon.org> writes:

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 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.

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.