Re: [PATCH 2/2] reflog: ignore expire-unreachable for "HEAD" reflog

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

 



On Thu, 15 Apr 2010, Junio C Hamano wrote:

> Nicolas Pitre <nico@xxxxxxxxxxx> writes:
> 
> > I'm a bit worried about this discussion.
> >
> > What's the point of having a reflog for unreachable stuff if it is to be 
> > pruned faster than stuff that is already reachable without any reflog?
> 
> To keep recently failed experiments alive for some time (30 days), but not
> overly long (90 days)?

What is a "failed" experiment is still subjective.  It might be possible 
to realize that part of it was not that bad after all and some pieces 
could be worth cherry-picking.

Again, keeping reflogs 90 days for stuff that is _already_ reachable 
through existing refs is much less useful than keeping otherwise 
unreachable stuff 90 days.  So I still don't see the point of this 
eagerness to prune deleted stuff faster.

If you explicitly want to get rid of failed experiments then it should 
be done through an explicit prune command.  Otherwise I'd argue that 
reflogs should take care not to lose track of unreachable stuff, even 
more so than stuff already reachable.

Some people even tried to convince me that reflogs should never expire 
by default, and that the 3 month grace period was already too short.


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