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

From: Junio C Hamano <gitster@pobox.com>
Date: May 28, 2008, 18:37 UTC
Message-ID: <7vskw2tgu2.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.1.00.0805281326520.19665@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 16 quoted lines

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

Now that is somebody who thinks before types.

Marking that the filesystem does not match what's in index is already done, so you could argue that an alternative would be not to stop in the middle of checkout_entry() loop and instead check out as much as we could, write out the index perhaps, and signal error, _AFTER_ updating everything else, including the HEAD. We try to be atomic when able (e.g. on a broken patch, "apply" does not apply early half the patch and fail but rejects the whole thing), but checkout_entry() loop is not something you can sanely make atomic (it needs to first remove existing files and even directories before writing new files), so that alternative approach might be easier to work with.

Care to follow it up with a patch?