[PATCH] mercurial: fixes update --clean to work on new branch (issue5003)

[Piotr Listkiewicz]

I hope im not too stubborn, but im still interested in fixing this, or any
reply about code-review, issue etc

2016-02-02 22:38 GMT+01:00 Piotr Listkiewicz <piotr.listkiewicz at gmail.com>:

> Issue is still not resolved and i am still interested in fixing this
>
> 2016-01-17 19:25 GMT+01:00 Pierre-Yves David <
> pierre-yves.david at ens-lyon.org>:
>
>>
>>
>> On 12/31/2015 11:48 AM, Sean Farley wrote:
>>
>>>
>>> Augie Fackler <raf at durin42.com> writes:
>>>
>>> On Wed, Dec 30, 2015 at 08:55:38PM +0100, liscju wrote:
>>>>
>>>>> # HG changeset patch
>>>>> # User liscju <piotr.listkiewicz at gmail.com>
>>>>> # Date 1451505270 -3600
>>>>> #      Wed Dec 30 20:54:30 2015 +0100
>>>>> # Node ID a92bf43906f58c665c35bc745e6d83049a2e95c2
>>>>> # Parent  23541bdd1610c08af247f9c8719045cf247ce541
>>>>> mercurial: fixes update --clean to work on new branch (issue5003)
>>>>>
>>>>
>>>> I'm somewhat unconvinced. What's wrong with 'hg revert --all' in this
>>>> case?
>>>>
>>>> (Other reviewers, please chime in - I'm not opposed to this, it just
>>>> seems a little quirky to me, and has implications for topics and some
>>>> other experimental work as well.)
>>>>
>>>
>>> I'm inclined to think --clean should work on new branch since we have
>>> 'hg up -C' work on a bookmark without deactivating it.
>>>
>>
>> Given that the "new" branch have not been commited yet, and --clean is
>> about "discard uncommitted changes (no backup)", I think we should discard
>> uncommited branch data in all case.
>>
>> To rephrase, with --clean, the branch used for the update logic should
>> -always- be the on of the first working copy parents. Uncommited branch
>> data, (new or not), should be disregarded.
>>
>> We could add a warning message for clarity.
>>
>> Does that seems an appropriate and consistent behavior to you?
>>
>> Cheers,
>>
>> --
>> Pierre-Yves David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160210/72b93ce4/attachment.html>