Re: git on Cygwin: Not a valid object name HEAD

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: git on Cygwin: Not a valid object name HEAD

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:28

Linus Torvalds [off-list ref] writes:
On Tue, 7 Aug 2007, Steffen Prohaska wrote:
quoted
Is there any chance that patches would be accepted that try to
do so? Even if they add "b" to fopen and O_BINARY to open, which
both are useless on Unix?
I certainly don't think it would be wrong to add O_BINARY to the open() 
parameters (and "b" to fopen() and friends), if it makes a difference.

Add a

	#ifndef O_BINARY
	#define O_BINARY 0
	#endif

and it should be harmless anywhere else.
Heh, you beat me to this ---  I like it.
quoted hunk
@@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
...
+static void close_or_die(int fd, const char *file)
+{
+	if (close(fd))
+		die("unable to close %s (%s)", file, strerror(errno));
+}
+
And I like this even better ;-).

Re: git on Cygwin: Not a valid object name HEAD

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:28


On Tue, 7 Aug 2007, Junio C Hamano wrote:
quoted
@@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
...
+static void close_or_die(int fd, const char *file)
+{
+	if (close(fd))
+		die("unable to close %s (%s)", file, strerror(errno));
+}
+
And I like this even better ;-).
Gaah, that was unintentional. Just random noise I had in my tree, and 
didn't even realize made it into the patch.

That "close_or_die()" was because I saw somebody report a write error 
without the error string, apparently because the error only got reported 
on the close (probably NFS). This way you see if the reason the close 
failed was due to out of diskspace or whatever.

But I should have split them up properly - the close_or_die() part 
obviously had nothing to do with the O_BINARY part. Feel free to take it 
regardless, or split it yourself.

		Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help