[PATCH RFC V2] localrepo: don't reintroduce pruned tag entries when tagging

[Augie Fackler]

On Wed, Feb 25, 2015 at 9:32 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 02/10/2015 06:42 PM, Augie Fackler wrote:
>>
>> On Wed, Feb 04, 2015 at 10:10:54PM -0500, Matt Harbison wrote:
>>>
>>> # HG changeset patch
>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>> # Date 1412209593 14400
>>> #      Wed Oct 01 20:26:33 2014 -0400
>>> # Node ID de7c57345dfc58a49c25f97070b084e65b1cb0a0
>>> # Parent  e1dbe0b215ae137eec53ceb12440536d570a83d2
>>> localrepo: don't reintroduce pruned tag entries when tagging
>>>
>>> If a commit and a followup tag commit are pruned, there are no references
>>> to it
>>> in any non obsolete version of .hgtags.  Without this change however, the
>>> next
>>> time a tag is added to another branch, the obsolete references are
>>> appended in
>>> .hgtags before the new entries for the current tag command.
>>>
>>> The annotation to unfilter localrepo._tag() has been around since
>>> b3af182a1944.
>>> The log message for it mentions computing the tag cache though, so I'm
>>> not sure
>>> if this was misplaced?  It looks like branchmap was aware of filtering
>>> then, and
>>> now tracks a cache per view.
>>
>>
>> This looks reasonable to me. Queued.
>
>
> This looks highly unreasonable to me ;-)
>
> The tags mechanism involves caching and needs to be aware of filtering level
> before we can move forward. Dropping the "unfiltered" decoration before that
> will likely cause obscure bug. Matt, description give me the impression that
> we need to dig deeper before dropping
>
>
> Can we drop/backout this?

I'm not sure what your objection is - do you think this introduces new bugs?

(It's queued largely because it resolves a bug, but I can be persuaded
that I'm missing something.)

>
>
> --
> Pierre-Yves David