Re-post from git@vger, in case someone stumbles upon this post:

Happy ending!

Turns out i have actually made a backup 3 days ago.

My other work was on a branch + in a stash. Commits done on a branch
were already present in a backup.
I was able to get the stash working by copying corrupted .pack files
from the backup, luckily all the new work wasn't packed yet.

So i've just verified the log messages to see that no new commits were
made, created a patch from the corrupted git repo of the stash,
applied it on the backup, and wo-hooo, everything worked.
And then I've pushed to origin to avoid such silliness in the future.

Thanks and Regards,

P.S. It's interesting to note that even though .pack files are
write-protected SED happily overrides them in -i mode.

On Mon, Jan 14, 2013 at 10:39 PM, George Karpenkov
<> wrote:
> Thanks, will try.
> No, it wasn't pushed anywhere, stupid, I know.
> On Monday, January 14, 2013 6:54:29 PM UTC+11, Konstantin Khomoutov wrote:
>> On Sun, Jan 13, 2013 at 11:19:53PM -0800, George Karpenkov wrote:
>> > Hi All,
>> >
>> > I've managed to corrupt my very valuable repository with a recursive sed
>> > which went wrong.
>> > I wanted to convert all tabs to spaces with the following command:
>> >
>> > find ./ -name '*.*' -exec sed -i 's/\t/    /g' {} \;
>> >
>> > I think that has changed not only the files in the repo, but the data
>> > files
>> > in .git directory itself. As a result, my index became corrupted, and
>> > almost every single command dies:
>> [...]
>> > .git/objects/pack/pack-0c9d5ae4e2b46dd78dace7533adf6cdfe10326ef.idx
>> > error: non-monotonic index
>> > .git/objects/pack/pack-e8bd5c7f85e96e7e548a62954a8f7c7f223ba9e0.idx
>> > Segmentation fault (core dumped)
>> >
>> > Any advice? I've lost about 2 weeks worth of work.
>> > Is there anything better I can try to do other then trying to
>> > reconstruct
>> > the data manually from git blobs?
>> Please ask this question on the main Git list (for developers)
>> which is git at (see [1] for more info) as it might
>> require assistance of people who know what's the format of Git packs on
>> the byte level.
>> As an aside: did you really never pushed your work anywhere for all of
>> those two weeks?  The problem is that what you did sounds to be hardly
>> reversible as Git packs probably contained a number of bytes with code
>> 0x20 (the space) before you turned each occurence of byte 0x09 in them
>> into a series of byte 0x20.
>> For an "I feel lucky" approach you could probably *copy* the directory
>> with your repository (recursively) to some other place and try to run
>> the same command on it as you did but with the arguments to the sed's
>> substitution command reversed.  If Git packs did not happen to contain a
>> series of 4 consecutive spaces before the change, you will revert them
>> back to normal.  Same applies to unpacked blobs but I feel chances are
>> lower in this case.
>> 1.
> --


Reply via email to