Will this feature come to diffusion for audit workflows?

Spaces have been working great for my install. The only real place where they're lacking I think arises from their coarseness/mutual-exclusivity.

This is somewhat implemented by D21315, which is headed to master soon. See also T13546 and T12876.

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:

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.

• When Piledriver destroys a resource pile, it's helpful if it can read the entire authoritative state from sources by using only a pile ID.
  • EC2 can do this with "DescribeTags".
  • Almanac currently can not. Almanac types should support searching by property value.
    • This could be directly on almanac.*.search.
    • Or this could be generic, via T12799.

Problem 2: Arcanist does not check that messages emitted by linters have a valid line number.