[PATCH V4] update: fix bare --clean to work on new branch (issue5003)

Piotr Listkiewicz piotr.listkiewicz at gmail.com
Fri Mar 11 02:35:46 EST 2016


>
> 1) bare `hg update` abort on new uncommited branch (with or without
> --clean)
> To me, the path for (1) is pretty clear, the "head" of the new branch is
> "wc" so we don't need to go anywhere. Your V4 apply this "update to parent"
> behavior only in the --clean case. We should apply it in all case (except
> maybe in the --clean case)..


I don't understand it. If we don't need to go anywhere, isn't going to
parent contradictive? Or if its treated like we don't need to go anywhere
because we stay on the same parent?

2) bare `hg update --clean` use working copy branch.
> The path for (2) is a bit fuzzier. --clean do "discard uncommitted changes
> (no backup)", including the branch change. So it seems a bit bizarre to
> stay on the head of a branch we are requesting to discard (and effectively
> discard in the new branch case). So in the --clean case we should probably
> use branch of p1() instead of branch of wc().

 This is actually exactly what your V1 was doing, but we got confused
> between fixing (1) (that requires something like you V4) and (2) were you
> were right.


For me its what V4 is doing. I'd be greatful for further explanations



2016-03-09 15:02 GMT+01:00 Pierre-Yves David <pierre-yves.david at ens-lyon.org
>:

>
>
> On 03/07/2016 09:34 PM, liscju wrote:
>
>> # HG changeset patch
>> # User liscju <piotr.listkiewicz at gmail.com>
>> # Date 1456249877 -3600
>> #      Tue Feb 23 18:51:17 2016 +0100
>> # Node ID 81a26b0f08ed54b86937be8765bc0b6f0899a27f
>> # Parent  c7f89ad87baef87f00c507545dfd4cc824bc3131
>> update: fix bare --clean to work on new branch (issue5003)
>>
>> So far 'hg update --clean' on newly created branch results in abort
>> with branch not found error. After applying this patch bare --clean
>> update results in updating to the first parent of working
>> directory without recreating the newly created branch.
>>
>> Another possibility of fixing this issue suggested in bug report
>> would be to recreate branch after update, but this behaviour
>> would be against the idea of --clean option: to discard changes
>> in working directory which includes marking it as new branch.
>>
>
> ARg, I just realised we are mixing two things here :-/ Sorry for not
> spotting that earlier.
>
> There is two issues here:
>
> 1) bare `hg update` abort on new uncommited branch (with or without
> --clean).
> 2) bare `hg update --clean` use working copy branch.
>
>
> To me, the path for (1) is pretty clear, the "head" of the new branch is
> "wc" so we don't need to go anywhere. Your V4 apply this "update to parent"
> behavior only in the --clean case. We should apply it in all case (except
> maybe in the --clean case).
>
> The path for (2) is a bit fuzzier. --clean do "discard uncommitted changes
> (no backup)", including the branch change. So it seems a bit bizarre to
> stay on the head of a branch we are requesting to discard (and effectively
> discard in the new branch case). So in the --clean case we should probably
> use branch of p1() instead of branch of wc().
>
> This is actually exactly what your V1 was doing, but we got confused
> between fixing (1) (that requires something like you V4) and (2) were you
> were right.
>
> Conclusion:
>
>   If my analysis make sense and people agree with it, we probably need two
> patches:
>   * one to fix `hg update` with uncommited new branch change
>     (similar to the V4)
>   * one to fix branch used by `hg update --clean` with uncommited branch
> (new or not).
>     (similar to the V1)
>
> Deeply sorry for the confusion.
>
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160311/12d9d799/attachment.html>


More information about the Mercurial-devel mailing list