Should nothing-to-rebase still move active bookmarks?

Durham Goode durham at fb.com
Wed Mar 13 16:17:48 CDT 2013


On 3/13/13 1:48 PM, "Kevin Bullock" <kbullock+mercurial at ringworld.org>
wrote:

>On Mar 13, 2013, at 12:40 PM, Siddharth Agarwal wrote:
>
>> Consider the following repo, where A and B are bookmarks:
>> 
>>  o--o--o(B)
>>   \
>>    -o (A)
>> 
>> At this point, doing
>> 
>> $ hg update A
>> $ hg rebase -d B
>> 
>> will move A's commit onto B, or in other words A ahead of B.
>> 
>>  o--o--o--o (A)
>>       (B)
>> 
>> However, when A is an ancestor of B:
>> 
>>  --o--o--o (B)
>>   (A)
>> 
>> the above commands will do nothing.
>> 
>> Compare to git, where even if A is an ancestor of B, if A is active
>>rebasing it onto B will move A and B to the same commit.
>> 
>> One of our engineers hit this while trying to do "make A depend on B".
>>Depending on whether A is an ancestor of B or not, the engineer has to
>>either rebase or do something like `hg bookmark -f -r B A`.
>> 
>> I think git's behaviour makes a lot of sense here. Is it possible to
>>reconcile that with hg's principles?
>
>How differently would you feel about this situation if moving the
>bookmark didn't require --force?
>
>This is largely the same consideration going on in a different thread,
>but regarding rebase instead of merge.
>
>pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
>Kevin R. Bullock

In an average user's workflow 'hg pull --rebase' is the incantation they
use when they want the latest bits and want to work on top of it.  I think
having a second step to achieve this (even without -f) in certain
non-obvious situations is confusing.  I think it makes sense to move the
bookmark up in this case (assuming there aren't any horrible backwards
compatibility issues).



More information about the Mercurial-devel mailing list