[PATCH STABLE] record: fix record with change on moved file crashes (issue4619)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Mon Apr 27 17:41:52 CDT 2015



On 04/27/2015 01:56 PM, Augie Fackler wrote:
> On Fri, Apr 24, 2015 at 12:07:18AM +0100, Pierre-Yves David wrote:
>>
>>
>> On 04/23/2015 06:34 PM, Matt Mackall wrote:
>>> On Thu, 2015-04-23 at 17:11 +0000, Laurent Charignon wrote:
>>>>
>>>> On 4/22/15, 5:22 PM, "Matt Mackall" <mpm at selenic.com> wrote:
>>>>
>>>>> On Wed, 2015-04-22 at 14:57 -0700, Laurent Charignon wrote:
>>>>>> # HG changeset patch
>>>>>> # User Laurent Charignon <lcharignon at fb.com>
>>>>>> # Date 1429736190 25200
>>>>>> #      Wed Apr 22 13:56:30 2015 -0700
>>>>>> # Branch stable
>>>>>> # Node ID 827224ee690234eb78e3c12ddcc381879bfba014
>>>>>> # Parent  1f9127c9239b9c39c676bb09752db1e2ca6c26f7
>>>>>> record: fix record with change on moved file crashes (issue4619)
>>>>>
>>>>>> reverting 79fceed67676, add a test to prevent the issue from coming
>>>>>> back.
>>>>>
>>>>> So.. this means we lose the fix to the legitimate bug that was in that
>>>>> change ("record: allow editing new files (issue4304)"), right?
>>>> Correct
>>>>> What's
>>>>> the plan here?
>>>>
>>>> Since this issue is a regression and I didn't feel confident getting the
>>>> right fix by the end of the week, I preferred rolling back the change that
>>>> caused it.
>>>> I will reopen issue4304 and work on the correct fix after, if that works
>>>> for you.
>>>
>>> Ok, sounds good. I just like to know what the plan is when we're trading
>>> one fix for another. This is queued for stable.
>>
>> If we "unfix" the new file issue, we should probably mark `commit -i` as
>> "experimental" (DEPRECATED) because it is not ready for prime time without
>> it.
>
> This makes sense to me

The unfixed bug have apparently been refixed.

.--
Pierre-Yves David


More information about the Mercurial-devel mailing list