Re: [PATCH] logging branch deletion to help recovering from mistakes

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

 



Jeff King <peff@xxxxxxxx> wrote:
> On Tue, Dec 07, 2010 at 10:37:39AM -0800, Shawn O. Pearce wrote:
> 
> > Yes, you are right.  We should instead let the normal reflog expire
> > action do its work here, and delete the empty log file when it is
> > finally empty.
> > 
> > I guess we also need repack and prune to enumerate these deleted
> > reflogs and retain the objects their records point to.
> 
> Definitely. I sort of assumed all of those things just traversed
> .git/logs blindly without regard to whether there was a ref, which would
> handle this automagically. But maybe that is not the case.

I think those enumerate the logs of refs that are also being
traversed.  Which means we would need to add new logic to enumerate
the deleted reflogs.
 
> Is there a reason to require that each log is specifically tied to a
> ref?

Historical bad assumptions?

I mean, no, there really isn't a good reason that each log is
tied to a ref.  Its probably reasonable to just enumerate the logs
directory separate from the refs directory enumeration.  Its just
some more code.  Right now we discover logs by just relying on the
ref directory traversal code.

-- 
Shawn.
--
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]