[PATCH 3 of 6 V2] rebase: use scmutil.cleanupnodes (issue5606) (BC)

Martin von Zweigbergk martinvonz at google.com
Sat Jul 8 02:17:15 EDT 2017


On Fri, Jul 7, 2017 at 11:15 PM, Jun Wu <quark at fb.com> wrote:
> Excerpts from Martin von Zweigbergk's message of 2017-07-07 23:08:29 -0700:
>> On Fri, Jul 7, 2017 at 11:04 PM, Jun Wu <quark at fb.com> wrote:
>> > Excerpts from Martin von Zweigbergk's message of 2017-07-07 22:59:55 -0700:
>> >> I just checked that the obsmarkers are produced in deterministic order
>> >> (independent of dict iteration order). However, bookmarks get moved in
>> >> dict iteration order. Maybe we should make sure that's also
>> >> deterministic? Can probably move the sorting you do for obsmarkers a
>> >> bit earlier and reuse that sorted list of tuples.
>> >
>> > Good point. I guess it is not causing problems since no test tests the
>> > "moving bookmarks" debug message. But "debugobsolete" does rely on marker
>> > orders. Maybe we need to make the debug message exposed somewhere and fix
>> > the sorting.
>>
>> I now see that I wasn't very clear, but the obsmarkers already seem to
>> be created in a deterministic order (by increasing source rev number).
>> It's just that the bookmarks that should probably be moved in the same
>> order.
>
> I think I understand what you mean. IIUC, bookmark movement order only
> affects the order of printing the debug message "moving bookmarks %r from %s
> to %s". We don't have tests for that debug message yet so the undefined
> order isn't causing issues (like, it does not change the end result of
> .hg/bookmarks)

Exactly.


More information about the Mercurial-devel mailing list