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

[Pierre-Yves David]

On 03/03/2015 02:04 PM, Matt Mackall wrote:
> On Wed, 2015-02-25 at 20:20 -0500, Matt Harbison wrote:
>> On Wed, 25 Feb 2015 09:32:13 -0500, 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 ;-)
>>
>> LOL.  I knew a change so simple was too good to be true.
>>
>> Assuming Greg's cache patches are OK, maybe this should be grafted to
>> stable?  The only reason I put it on default was because I wasn't sure of
>> any unexpected side effects.  It isn't a critical bug for 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?
>
> For better or worse, this landed on default. So if people think this is
> wrong, they should probably submit a follow-up.

I've pushed a backout to the clowncopter.

-- 
Pierre-Yves David