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

Piotr Listkiewicz piotr.listkiewicz at gmail.com
Wed Feb 24 18:17:30 EST 2016


>
> Not super enthousiastic about this behavior. Could we just not update
> anywhere in that situation? Without the abort, possibly with a message
> mentionning thate uncommited branch foo does not exist yet, so we are not
> updating anywhere.


This behaviour would be perfectly reasonable too

Why do we need this? if clean, won't wc.branch() return the same thing as
> repo["."] branch?


If branch is newly created wc.branch() is different than its first parent
(repo["."]), if branch is the same for working directory as its first
parent then it preserves old behaviour.

Clean option doesn't tell if working directory has the same branch as first
parent or not, or i just don't understand sth.

Here, we could check if the branch exist in the repository at all and issue
> a special message if not.


 Ok, i will change this behaviour in next patch

2016-02-24 23:54 GMT+01:00 Pierre-Yves David <pierre-yves.david at ens-lyon.org
>:

>
>
> On 02/23/2016 07:40 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 541ba7dc5f2667298c3ff2d72e5c05559a79ba92
>> # Parent  91a827e760df9d9b3d86692c5aa195a3d6ba2208
>> mercurial: fixes update --clean to work on new branch (issue5003)
>>
>> So far 'hg update --clean' on newly created branch results in abort
>> with branch not found error. Before this patch the destination node
>> was resolved using instruction:
>>
>> node = repo.revs('max(.::(head() and branch(%s)))'
>>                           , wc.branch()).first()
>>
>> Problem occures when wc.branch() is newly created branch in
>> working directory, so there are no changeset having branch
>> the same as branch in working copy.
>>
>> This patch fixes this problem by searching for revision having
>> the same branch as first parent of working directory.
>>
>
> Not super enthousiastic about this behavior. Could we just not update
> anywhere in that situation? Without the abort, possibly with a message
> mentionning thate uncommited branch foo does not exist yet, so we are not
> updating anywhere.
>
> diff -r 91a827e760df -r 541ba7dc5f26 mercurial/destutil.py
>> --- a/mercurial/destutil.py     Sun Feb 14 01:33:55 2016 +0900
>> +++ b/mercurial/destutil.py     Tue Feb 23 18:51:17 2016 +0100
>> @@ -91,13 +91,17 @@ def _destupdatebranch(repo, clean, check
>>       """decide on an update destination from current branch"""
>>       wc = repo[None]
>>       movemark = node = None
>> +    if clean:
>> +        branch = repo["."].branch()
>> +    else:
>> +        branch = wc.branch()
>>
>
> Why do we need this? if clean, won't wc.branch() return the same thing as
> repo["."] branch?
>
>       try:
>>           node = repo.revs('max(.::(head() and branch(%s)))'
>> -                         , wc.branch()).first()
>> +                         , branch).first()
>>           if bookmarks.isactivewdirparent(repo):
>>               movemark = repo['.'].node()
>>       except error.RepoLookupError:
>> -        if wc.branch() == 'default': # no default branch!
>> +        if branch == 'default': # no default branch!
>>               node = repo.lookup('tip') # update to tip
>>           else:
>>               raise error.Abort(_("branch %s not found") % wc.branch())
>>
>
> Here, we could check if the branch exist in the repository at all and
> issue a special message if not.
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160225/efff4dcf/attachment.html>


More information about the Mercurial-devel mailing list