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.

Problem 3: The cpplint unit tests fail, and the failure appears to be pre-existing and significant.

• Problem 4: If a file ends in non-newline whitespace, the text linter may raise a message which removes that line. The renderer then tries to highlight part of it, which fatals.

Here's a simplified reproduction case for "Problem 1":

• Problem 1: cpplint may raise messages at line 0, but arcanist can not render these messages after the severity of runtime-level errors was increased in D21044.

Effectively mooted by T13542.

I've written some Terraform-class tooling which can likely automate all the actual hardware allocations. This needs some more work, but I believe the tricky stuff (mostly: representing resources and allowing templating to reference resources which haven't been built yet) is at least working.

Subnet/NAT issues in T12816.

Continued in T13542.

The major offender here (services per instance) was fixed by updating caching, and I destroyed all the old services. This is perhaps spiritually continued in T13542.

Continued in T13542.

Continued in T13542. I wrote a Terraform/CloudFormation-style service in PHP over the last couple of days.

Continued in T13542.

Committer identities ... they're currently stored in a JSON blob so there's no efficient way to query them.

That was sufficient to get what I needed, thanks so much.

Is there a way to find which object(s) an (unmapped) identity was discovered on?

Is there a way to find which object(s) an (unmapped) identity was discovered on? After a rebuild-identities, I have an empty string identity and a couple asdf-style garbage ones. I'd like to find the source of them and either fix them there or see the context to understand the appropriate identity mapping.

• In previews, suggestions aren't highlighted properly (likely just missing CSS).

(there's usually no value in reviewing individual file-level changes in a "create a new branch X" commit)

Completely agree that there's no value in reviewing those individually. But to be clear, my point in making this ticket was mostly that you can't discern from the browser that this was a "create a new branch" commit. Right now it just renders the whole file tree saying showing 3000 files individually copied instead of a simpler/single line saying the whole directory was copied.

Since many of these options probably don't have "right answers", I'm trying this reasonable-seeming variation on some repositories which seem like they'll benefit from a repack:

• j, etc., can incorrectly select blocks inside a diff inside a suggestion.

See PHI1748. I ran a query against a subset of instances to determine how widespread usage of "Dark Mode" is, to help inform a decision to either implement the mode properly (see T12311) or remove the mode. The query was of this form:

I think (?) this was pretty much resolved by the last round of changes. See T13291 for some followups.

I made a change to drop unchanged context from suggestion views, but I don't particularly like it. It changed this:

• Inline comments with suggestions don't "know" that they're empty when the suggestion is the same as the context text.
  • Create an inline. Suggest edit. Don't change anything. Save. You get a blank inline with no suggestion and no content, when this inline would normally delete itself.

The inline comment context menu does not apply the correct cursor ("pointer").

I still have a lot of inline style attributes to clean up and then I'm sure there will be a long tail of weird edge cases, but this is getting pretty close:

• This isn't necessarily terribly useful in practice, but a UI hint about whether or not we've actually saved a draft would make debugging slightly easier.

Remaining work here is:

• The inline comment context menu does not apply the correct cursor ("pointer").

These particular issues blame to D21027, which began extracting null in all cases where a field has no value for a given commit. This is not entirely faithful, as it can not distinguish between "field absent" and "field present, but with an empty value". At least for author, these are distinct states that can be independently constructed using git hash-object:

From PHI1739, --allow-empty-message supports constructing these commits more easily (via a normal git commit rather than git hash-object).

Second issue:

First issue:

Alas, you can't actually push the perfect commit: