This is an archive of the discontinued Mercurial Phabricator instance.

rebase: move working parent movement logic to scmutil.cleanupnodes
AbandonedPublic

Authored by durin42 on Sep 18 2017, 4:20 PM.

Details

Reviewers
durham
quark
Group Reviewers
hg-reviewers
Summary

Moving working parent is a common requirement that could be shared in other
places. This patch makes it possible.

This would make rebase more solid since the bookmark movement and working
parent movement is strongly guaranteed to share same rules.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

quark created this revision.Sep 18 2017, 4:20 PM
quark edited the summary of this revision. (Show Details)Sep 18 2017, 4:32 PM
pulkit added a subscriber: pulkit.Sep 18 2017, 4:34 PM

How about having a new upper level function which handles all these things and also call scmutil.cleanupnodes? Maybe we can add phases logic in that function also afterwards.

quark added a comment.EditedSep 18 2017, 4:40 PM
In D728#12181, @pulkit wrote:

How about having a new upper level function which handles all these things and also call scmutil.cleanupnodes? Maybe we can add phases logic in that function also afterwards.

It seems that you want a copyphase=True|False flag which could be added to cleanupnodes.

For working copy movement, it shares the logic with bookmark movement so it's unlikely to be a separate method.

I'm wondering if hg.cleanupnodes would be a better place than scmutil since it's getting more complex (and it also solves import cycles).

In D728#12194, @quark wrote:
In D728#12181, @pulkit wrote:

How about having a new upper level function which handles all these things and also call scmutil.cleanupnodes? Maybe we can add phases logic in that function also afterwards.

From these I mean bookmark+wdir.

It seems that you want a copyphase=True|False flag which could be added to cleanupnodes.
For working copy movement, it shares the logic with bookmark movement so it's unlikely to be a separate method.
I'm wondering if hg.cleanupnodes would be a better place than scmutil since it's getting more complex (and it also solves import cycles).

I was suggesting a function like hg.updatenodes(mapping, wdir, phase) which handles (phase+wdir+bookmark) and calls smcutil.cleanupnodes. That sounds cleaner but we need to extract the bookmark logic and maybe we cannot do that. :(
I was also concerned about it getting more complex. I was also going to add a formatter argument to it.

quark added a comment.EditedSep 18 2017, 5:00 PM

From these I mean bookmark+wdir.
I was suggesting a function like hg.updatenodes(mapping, wdir, phase) which handles (phase+wdir+bookmark) and calls smcutil.cleanupnodes. That sounds cleaner but we need to extract the bookmark logic and maybe we cannot do that. :(

Suppose there is a higher-level hg.updatenodes calling today's scmutil.cleanupnodes, what's the use-case of calling scmutil.cleanupnodes directly? If no, I'd prefer less APIs to make it harder for extension developers to make mistake.

I was also concerned about it getting more complex. I was also going to add a formatter argument to it.

I think formatter should be a separate method. Suppose rebase can output more than just "changes", ex. the user runs rebase -T '{changes} {rebasesource} {rebasedest}, it's not cleanupnodes to resolve the template. What you need is something to register changes as part of the template function context so the template engine knows how to resolve the name changes.

durham requested changes to this revision.Sep 26 2017, 8:10 AM
durham added a subscriber: durham.
durham added inline comments.
mercurial/scmutil.py
603

This seems like a bit of a bizarre feature for an api about cleaning up nodes. Maybe cleanup nodes should return a mapping of before-to-after and the caller can use that to perform an update if they need to? I'd rather have APIs that can be composed, than add new permutations to existing APIs.

This revision now requires changes to proceed.Sep 26 2017, 8:10 AM
quark added inline comments.Sep 26 2017, 1:03 PM
mercurial/scmutil.py
603

The function is to make it easier to do common tasks: obsolete/strip, move bookmarks, move working parent. Since we have bookmark movement already. It makes sense to me to also have working parent movement.

I agree the API could be split, so bookmark and working copy movement could be used independently. But cleanupnodes is intended to be the composed function.

durin42 commandeered this revision.

Let's reopen this if/when we return to it.

durin42 abandoned this revision.Oct 14 2017, 3:21 AM

Let's reopen this if/when we return to it.