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