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

-- 


Reply via email to