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

[Daniel Barkalow <barkalow@iabervon.org>]

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

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > 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.

Well, and I've got the background to know what's possible and how git can 
keep things straight.

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

Ah, yes, CE_VALID. But it doesn't quite work as well as I'd like, because 
it doesn't ignore fstat/readdir not finding anything on the filesystem, so 
it comes out looking deleted, at least if you're actually on Linux (with a 
hack in create_file to refuse to create certain filenames for testing).

Also "git mv CE_VALID-source dest" doesn't ignore the filesystem like it 
should (for this use, anyway). Perhaps we need an additional flag for "the 
filesystem is irrelevant for this entry".

> Care to follow it up with a patch?

Unfortunately, I don't think I'll have a chance for a while to actually 
work on git code. But if someone else (Avery?) wants to try it, I think 
giving a big warning, setting CE_VALID, and returning 0 in entry.c before 
the "unable to create file" message is the right thing to start with. And 
someone with Windows access should figure out what happens next.

I think the right test for this is if create_file() returns EEXIST, but 
readdir doesn't show anything. For that matter, it might be useful to have 
logic 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.

	-Daniel
*This .sig left intentionally blank*