Re: Recovering from a bad object

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 22, 2011 at 6:31 PM, jonsmirl@xxxxxxxxx <jonsmirl@xxxxxxxxx> wrote:
> Looks like the corrupt object is ok in the object store.
>
> I checked out about 20 of the dangling objects. They all start off with...
>
> commit aa96dc2459563fa362bc53597cb076d93bcc884a
> Author: Jon Smirl <jonsmirl@xxxxxxxxx>
> Date:   Sat Mar 19 13:30:55 2011 -0400
>
>    refresh (create temporary patch)    d666137c5fe3ee4c4c812c706b1a3c539405ffd0
>
>
> That's stgit leaving all those dangling references. I will experiment
> with the current stgit and see if it is still leaving the dangling
> references or if they are leftovers from an old bug.

I've confirmed it is a problem in stgit. I made a brand new clone and
did three refreshes in it.

jonsmirl@terra:/home/apps/lpc3131/linux$ git fsck
dangling commit 78fe5e16791996ffa3e60eb8015c8782c02496ca
dangling commit 5d41f5a4368036f18a021a8e72ad5577839070c6
dangling commit b3b2be2f2a78d356059d92dbb937f9df726de166

Now I have three dangling commits.

Now I don't know enough about stgit works. Are those really dangling
commits from stgit abandoning temporary commits, or is stgit tracking
them and 'git fsck' simply doesn't have a reference to them.

>
> --
> Jon Smirl
> jonsmirl@xxxxxxxxx
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]