On Wed, 28 May 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
