@jhurwitz and I made some effort toward this mid-last-year, but the backfill script is still not quite working. Figure I'd put up the progress.

There are many existing failures in our codebase. Linting all files would give copious (unhelpful) output. That being said, I haven't tried it because it would (probably) take hours to run. Should I give it a try?

That prioritization makes sense to me. It doesn't seem worth putting a lot of effort into optimizing the workflow for a bad configuration.

I was able to get some metrics for how many revisions have lint errors in this particular project (repo callsign 'C') with this query:

1. In this case I was yes.
2. We have post-push builds hooked up, but not pre-push for this project in particular. (rely on arc unit)
3. We have tests only run on affected files, but we have certain files that can trigger a lot of tests.
4. I'm all for this (reducing some big categories from warning to advice by default). Going to try to make it happen. Would be cool to have a list of "top errors in this project" somewhere to make this process easier.

Ah yes, this should be a feature request and not a bug report. Sorry!

I saw it as two subproblems

1. Difficulty remembering whether lint or unit failed
2. Difficulty remembering excuse for lint failures in particular.

Fix comment from 10->60

Only change the constants. No extra option

Increasing seems reasonable to me too. The problem I see is a 4.1MB gif which doesn't get thumbnailed for the pinboard view. It's not a major issue, but it seemed one that was avoidable.

Running unit tests

+1. I agree that conflicting rules are un-resolvable (and thus a configuration issue), but in this case, even consistent rules cause an issue.

Nope totally sounds reasonable.
I think the thing that was weird to me was that I was able to accept from the UI after it was already in an accepted state, but since I had an old session, sure do it twice.

I honestly am not sure how I ended up in the state where there were two commits against one revision. I was splitting one revision into two and unfortunately, I'm not exactly sure what I did at the time. I believe it was a git rebase -i HEAD^ followed by git add -p followed by git commit and git rebase --continue, but there may have been some more nuance to it.

Sgtm

I'm don't see why the number-of-rules is relevant

Ah you are right. You can see the set of conditions that were checked for the rule.
In my particular case, I wanted to find the rule that was adding me as a subscriber and disable it.
I ended up typing "/herald/rule/(rulenumber)" into my URL bar to get to the page of the rule.

I went back to repro this and realized that my repro steps weren't perfect. On second thought, this seems like an expected behavior, but it still threw me for a bit of a loop. I had created one commit and split it up into two (the first of which was trivial and could skip review). I think the behavior is reasonable - I just didn't realize why it had associated branch A with the revision on branch B.

As a tangent, this flow also leaks slightly in that the end of arc land output says "you can get this commit back by..." and the SHA that it tells you is the SHA of the merged commit, not the tip of the branch that you originally had.

Sure. I'll try to describe the problem we ran into.

Got the backfill migration script to work on DifferentialTransactionComment.
Still can't quite get it working in the general case. I feel like I misunderstand
PhabricatorApplicationTransaction and PhabricatorApplicationTransactionComment
Thx

Moved logic to remarkup rules.
Couldn't quite get the backfill migration script working. Looking for some help there.
Otherwise, it works great.

Macro was targeted at myself of course

Hey cool!