See also vaguely-related T8952.

This is now fully configured.

I ultimately don't think there's any really reasonable way we can fix this that doesn't have a cost and complexity far greater than the benefit.

This has been live for some time without any apparent issues.

We haven't seen further reports of this in more than two months, so I don't plan to mitigate it at the application level.

Presuming resolved by getPathChangedLines($path) + -lines.

This request doesn't describe a root problem, so we can't develop a solution to it. We haven't received any new information in more than a month. See Describing Root Problems and Contributing Feature Requests for help describing root problems and filing feature requests that the usptream can accept.

We can't reproduce this and we haven't learned any new information in more than a month, so I'm going to close it.

This report does not include reproduction steps. Bug reports must include complete, self-contained reproduction steps to be accepted by the upstream. See Providing Reproduction Steps for help.

I'm going to merge this into T10563 which is narrower but more actionable.

We don't have enough information about this problem to design a solution, and haven't received more information in more than a month. See Describing Root Problems and Contributing Feature Requests for details on how to submit an actionable feature request.

I think you are missing some steps, like that you need to set the edit policy to something fairly restrictive. @richardvanvelzen is correct though, you can unlock this from the command line and archive the project. You can also use bin/remove to permanently nuke objects, but it's not recommended.

@camilorojas I think I just added the following file

You can probably use bin/policy unlock to open up the policy.

T10469 is probably the best solution there.

One followup request from D14935: Show the workboard column along with the project. Obviously there is a space vs information value tradeoff, but if workboard columns are relevant anywhere wouldn't it be in Workboards? This was feedback from one of our product managers who looks at many different workbaords, not just a single team's.

Take a look at this and see how far you can get? It might be really easy but it might also be very involved.

It's currently impossible to sort badges by rarity because they rarities are internally 'grey', 'white', 'green', etc., and there is no natural order to these. For example, MySQL has no idea what order 'indigo', 'orange' and 'yellow' should go in, except alphabetical, which is not actually the correct order.

I think this is a feature request, but feel free to switch projects if it's a bug.

Sounds good, let us know if you run into anything else.

Latest version seems to have fixed this. Sorry for the noise, and thanks for building such an awesome software.

For completeness, T10651 is the earlier report.

I think this should now be resolved in HEAD of master. It will likely promote to stable in about 24 hours.

(fantastic bug reporting, otherwise)

I think that stuff isn't linking because someone is pushing their own branches to the upstream staging repository, making the commits ambiguous. That is, e3f89279f912 is ambiguous as either rPe3f89279f912 or rSTAGINGe3f89279f912.

rPe3f89279f912 should have resolved this, I believe.

Doh. Give me a minute, testing with 3493d9d5138e0a630624bced548090163ce9be8a now.

Your install is out of date.

Ah, thanks! To hit this, I think we need to push a mixture of changes:

I've cloned the repo to a test machine, so I'm available to make more tests if you need

I've rolled back my state to better identify the steps.

The only way I can see to get to an error state is if both branches had the same head before the push? I'm not sure how to build that state, although maybe I'm just missing some subtlety of hg branch or some sequence of merge/close operations which can force it.

Using mercurial push a set of commits that updates multiple branches at the same time