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

[Piotr Listkiewicz]

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/20160202/7984a15d/attachment.html>