Just extracting a few blocks of old code for reference:

I may actually make the minimum version whichever version has this fix:

Today, arc land in Mercurial does not support the "merge" land strategy.

I am dropping support for versions of Mercurial older than 2.1.1 (released in May, 2012). This is the first version that: (a) has phases and (b) does not exit 1 when hg pull succeeds but fetches no changes.

After changes connected to T13546, the git workflow now looks like this:

After near-future changes connected to T13546 this is ripe for implementation, but I don't think it has come up again in ~6 years so I'm not sure it's actually worth improving. arc has also warned about abandoned revisions for a long time, which may have mooted this. My expectation is that the modern behavior is clear and the remedy is simple (arc land --revision 123) but I'm open to reconsidering this once the changes connected to T13546 have stabilized, if it's still an issue then.

After near-future changes connected to T13546, arc.land.onto (previously arc.land.onto.default) has higher priority than upstream branches.

Changes connected to T13546 address this, see T13547 for a preview of new behavior.

See PHI1013, which would like a way to specify that the branch you want to merge into might be different from the name of the branch you want to push into the remote.

I think the general shape of this is:

thanks. I can confirm the change lets the daemon finish the task and renders a reasonable diff.

arc diff has a lot of code to deal with handling untracked or uncommitted changes in the working copy. The major motivations for arc caring about this are:

I'm not sure --use-commit-message has any real use cases.

I think that this is something we(Wikimedia) can patch downstream in our fork, I don't think there is anything further to add to this upstream discussion.

Piledriver would also benefit from having some functional equivalent of destroying an Almanac resource. This can be implemented as a piledriver.destroyed property, but a formal disabled state would be cleaner. PHI1331 is vaguely related.

Bumping again simply because this has come up a few times this month. Teams I work with want to use a WIP feature, but don't use the current implementation because it tracks points instead of tasks. Reviewing the rest of the comments in this thread, all of it remains relevant to those use-cases.