"Avery Pennarun" [off-list ref] 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.
On Wed, May 28, 2008 at 7:24 PM, Junio C Hamano [off-list ref] wrote:
Please learn to think before typing, let alone sending such a message to
waste other people's time.
Why so harsh?
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.
Or instead we could have a '-f' switch or such with checkout that
allows you to checkout a revision that contains a bad file, but with
that file missing. Of course this needn't happen silently, a big
warning saying "could not checkout file %s because of %s" may still be
issued.
--
Cheers,
Sverre Rabbelier
On 5/28/08, Junio C Hamano [off-list ref] wrote:
Please learn to think before typing, let alone sending such a message to
waste other people's time.
Phew, just mentioning Windows on this list seems to get people flamed.
Reading over my message, I'm not sure what I would have written to
have it interpreted as being negative. I was simply suggesting that
git could fail more gracefully here.
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 part that's not surviving is git-bisect, which is a valid problem
that resulted in someone asking to rewrite the history. Clearly
rewriting the history is not a good solution, thus no good solution
has yet been proposed, which is why I wrote my message.
The system with a *fatal* error is not git but the one that does not want
an not-so-unreasonable name "NUL" on it.
That is clearly true. But knowing that doesn't seem to be making this
user's problem go away.
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.
If the file failed to be created (with a warning), but we treated it
as having been deleted in 'git status' instead of throwing an error,
it would work much like the case sensitivity problem: the index is
annoyingly dirty, but you can still get work done. I think that
(perhaps with a little patch) would allow git-bisect to work.
Have fun,
Avery
On Wed, 28 May 2008, Junio C Hamano wrote:
"Avery Pennarun" [off-list ref] writes:
quoted
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*