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 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
>
>
--
