git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: My git repo is broken, how to fix it ?

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Mar 19, 2007, 15:20 UTC
Message-ID
<Pine.LNX.4.64.0703190804350.6730@woody.linux-foundation.org>
In-Reply-To
<200703191932.26856.litvinov2004@gmail.com>
On Mon, 19 Mar 2007, Alexander Litvinov wrote:
Show 5 quoted lines
> 
> It is pity but my repo was corrupted again. I have WinXP + cygwin + 
> git-1.5.0-572-ge86d552. I was doing 
> git-apply/git-am/git-reset/git-cvsexportcommit and broke repo somehow. I have 
> two broken blobs that should be done by my recent patches.

Ok, can you send me just the two broken blobs? I assume that they are loose objects, so when fsck complaines about a corrupt object xyzzy..., just take those objects from

	.git/objects/xy/zzy..

and tar the two broken ones up, and send it to me by email. I'll keep it private if need be, but if you don't care about that, it would be even better if you can send them to the list publicly so that others can see what the corruption looks like.

> Is there any way to catch and solve the problem ?

I'd like to see the objects to look at what the corruption looks like, but I suspect that it's cygwin and/or WinXP. I'm not at all convinced that Windows is all that safe in general when it comes to data consistency, and I suspect cygwin makes it much worse by making operations that *should* be atomic be non-atomic.

Here's a patch that is probably a good idea to try. It disables the hardlinking code for CYGWIN, and it also checks for errors from "close()". Those are the two most obvious issues that I could imagine causing problems..

		Linus
---
 sha1_file.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 372af60..d829dc7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1760,6 +1760,14 @@ static void write_sha1_file_prepare(void *buf, unsigned long len,
 	SHA1_Final(sha1, &c);
 }
 
+#ifdef __CYGWIN__
+static int link(const char *old, const char *new)
+{
+	errno = ENOSYS;
+	return -1;
+}
+#endif
+
 /*
  * Link the tempfile to the final place, possibly creating the
  * last directory level as you do so.
@@ -1951,7 +1959,8 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
 	if (write_buffer(fd, compressed, size) < 0)
 		die("unable to write sha1 file");
 	fchmod(fd, 0444);
-	close(fd);
+	if (close(fd))
+		die("error closing sha1 file (%s)", strerror(errno));
 	free(compressed);
 
 	return move_temp_to_file(tmpfile, filename);
Previous: Alexander LitvinovNext: Linus Torvalds
Message 7 of 28 in “My git repo is broken, how to fix it ?”
  1. Alexander LitvinovFeb 28, 2007
  2. Linus TorvaldsFeb 28, 2007
  3. Alexander LitvinovFeb 28, 2007
  4. Linus TorvaldsFeb 28, 2007
  5. Alex RiesenFeb 28, 2007
  6. Alexander LitvinovMar 19, 2007
  7. Linus TorvaldsMar 19, 2007
  8. Linus TorvaldsMar 20, 2007
  9. Alexander LitvinovMar 20, 2007
  10. Junio C HamanoMar 20, 2007
  11. Nicolas PitreMar 20, 2007
  12. Linus TorvaldsMar 22, 2007
  13. Nicolas PitreMar 22, 2007
  14. Linus TorvaldsMar 22, 2007
  15. Linus TorvaldsMar 22, 2007
  16. Linus TorvaldsMar 22, 2007
  17. Nicolas PitreMar 22, 2007
  18. Linus TorvaldsMar 22, 2007
  19. Nicolas PitreMar 22, 2007
  20. Jeff KingMar 22, 2007
  21. Linus TorvaldsMar 23, 2007
  22. Bill LearMar 23, 2007
  23. Jeff KingMar 23, 2007
  24. git-apply: Do not free the wrong buffer when we convert the data for writeoutJunio C Hamano, Mar 22, 2007
  25. Linus TorvaldsMar 22, 2007
  26. Alexander LitvinovMar 23, 2007
  27. Alexander LitvinovMar 23, 2007
  28. Johannes SixtMar 22, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.