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

Re: Problem with pack

From
SCSergio Callegari <scallegari@arces.unibo.it>
Date
Aug 25, 2006, 10:07 UTC
Message-ID
<44EECBE2.7090801@arces.unibo.it>
Show 12 quoted lines
>
> > git verify-pack -v pack-ebcdfbbda07e5a3e4136aa1f499990b35685bab4.idx
> > fatal: failed to read delta-pack base object 2849bd2bd8a76bbca37df2a4c8e8b990811d01a7
>
> Eeeh! Not good.
>
> > 1) I am working on both a pc and a notebook, syncing the two everytime I move
> > from one to the other.
>
> So, you still have one "good" version? Please make a backup immediately. 
> (If only to reproduce the problem.)
>   

I have a good working tree, but unfortunately I realized that there was a problem with the pack only _after_ the sync: I was not expecting this kind of problem, so I silly did a repack as the last thing, I went home, I attached the laptop to the net, I run unison, I started to work and I realized that there was a problem when I attempted a new repack which failed complaining about the corrupted pack...

So actually, I do not even know where the corruption came from (an hd error, the sync tool, ...)

I only have the corrupted pack and its index and a good last working tree.

BTW, it would be nice to have some "security measure" in git reset... e.g. an option to trigger the following behavior:

- saving all current changes in a temporary commit
- checking that the current HEAD can be re-checked out before the reset
Show 5 quoted lines
> Since unpack-objects does not use the index, it cannot extract anything 
> after the first error. We _could_ enhance unpack-objects to be nice and 
> optionally take a pack-index to try to reconstruct as many objects as 
> possible.
>   

That would be very useful... Btw, even without that, if I understand correctly, git packs are collections of compressed objects, each of which has its own header stating how long is the compressed object itself. In my case, the error is in inflating one object (git unpack-objects says inflate returns -3)... so shouldn't there be a way to try to skip to the next object even in this case?

Show 5 quoted lines
> BTW I'd recommend not syncing with unison, but with the git transports: If 
> your PC and Laptop are connected, you could do something like
>
> 	git pull laptop:my_project/.git
>   

Actually, the project, including the git archive gets syncronized as a part of a syncronization process including all my Documents directory (the project is in fact a LaTeX manual with somehow complex LaTeX packages and classes). Syncronizing in this way actually worked very well so far, because at once I was getting in sync all my working trees and all my repos...

Sergio
Next: Andreas Ericsson
Message 1 of 6 in “Re: Problem with pack”
  1. Sergio CallegariAug 25, 2006
  2. Andreas EricssonAug 25, 2006
  3. Jakub NarebskiAug 25, 2006
  4. Junio C HamanoAug 25, 2006
  5. Junio C HamanoAug 26, 2006
  6. Junio C HamanoAug 26, 2006

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.