On Wed, 28 May 2008, Junio C Hamano wrote:
> "Avery Pennarun" <apenwarr@xxxxxxxxx> writes:
>
> > As an unhappy Windows user myself (sometimes), I think it might be
> > better to simply fix git to *survive* failing to create files like
> > 'nul' on Win32, rather than trying to *fix* such files in the repo.
> > It sounds (from the original post) like git has a *fatal* error
> > ("cannot be checked out on cygwin") when trying to create 'nul'.
>
> Please learn to think before typing, let alone sending such a message to
> waste other people's time.
>
> We give the user an error message, and signal error by exiting with
> non-zero. You cannot have that path on the system, and we are being
> honest about it. It is not like we are suddenly painting the screen in
> blue and refusing to get any more user input when you try to check out
> such a tree. Which part of that is _not_ surviving?
>
> The system with a *fatal* error is not git but the one that does not want
> an not-so-unreasonable name "NUL" on it. Git survives on such a system
> and tells you what happened --- you cannot do certain things, such as
> checking out such a tree. You live with it, or get a better system ;-)
>
> What alternatives do you want to implement? Certainly not silently
> creating "nul-garbage" file instead and pretend that nothing bad happened,
> as that would lead to madness.
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, rather than having to rely on
either read-tree/update-index --cachinfo/write-tree or a helpful user of a
non-broken system to get things working again.
Git should, I think, even be able to figure out by itself when to not
trust the filesystem; if open gives EEXIST, but readdir doesn't list it,
it's a filesystem problem and we should work around it.
-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
