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 vger.kernel.org (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. http://vger.kernel.org/vger-lists.html#git


Reply via email to