At least today, I don't think we can reasonably guess when a table is really a collection of side-by-side comparison images to do anything special with it. I think allowing block-level elements to change behavior based on content would require a total restructuring of how Remarkup parses, and make adding new rules far more complex (see also T10354).

I'm just going to merge this into T10337, which discusses providing modern endpoints. repository.create is a broken mess and we tend to replace it rather than fixing it (it can't reasonably be fixed without breaking the API, anyway, so we'd end up with a new endpoint in effect, regardless). The new diffusion.edit will fix this and the many other problems with repository.create.

The infrastructure changes should now be complete, and we're clear to start experimenting with the UI. Progress so far:

(This is paused since we're waiting on feedback -- if you give it a shot, let us know how things go.)

D15636 is marked as fixing this. Specifically:

I'm going to sort out the infrastructure issues first, then we can see where the UI goes. Specifically:

The use of sh as it is written in the documentation is important.

This should now be fully resolved in HEAD of master. Thanks for the report! Your details and stack traces were very helpful in understanding and resolving the issue.

After D15632:

Cool, let me see if I can repro that locally.

You should get a little further now in HEAD of master.

It looks like this is occurring during error handling so there's likely some other root error that this is masking, but we can fix this and see what it unveils.

(Oh, this one was with arc land --hold originally too -- I misremembered the context.)

T10727 is a similar report of this issue, although motivated via arc land --hold.

(That explanation might make approximately zero sense, I am not having a high-brain day today.)

This is probably the "object policy evaluated in the context of a different object" issue we've seen occasionally. If so, setting the visibility policy to any non-object-policy value (e.g., "All Users", or a specific list of users, etc -- anything which does not depend on the revision) should fix the error.

If we did add configuration, I think there are three ways we could do it:

A couple of general notes/thoughts:

Nice catch, thanks! D15619 should fix the docs.

• I'd currently consider this a user-expectation issue, but we're doing ourselves zero favors by not providing any kinds of hints about what expectation you should have. We should fix this first. I've realigned this task to discuss making the expectations/behavior more clear.
  • I believe the "edit permission is necessary" part of this rule is hard to reasonably get away from in light of column triggers (T5474). Not impossible, but hard.
  • The "edit permission is sufficient" part of this rule is easy to get away from, but we don't actually have use cases for requiring an additional project permission component right now (T6502).

My current expectation is that the rule is supposed to be that edit permission on the task is both necessary and sufficient to move it on the workboard, but this is almost certainly not fully reflected in the UI, and possibly not fully reflected in permission checks in some cases (?) although it sounds like we're good from this discussion.

The new *.edit endpoints can both create and edit, so a badges.create method would be redundant.

@psawant, thanks for the report and for your help building a reproduction case for us on a Phacility instance. It was extremely helpful in identifying and resolving the root cause of this issue.

A workaround is to give the repository a callsign Edit Repository → Edit Basic Information → Callsign.

This is a bug; see T10721 for followup and discussion.

Thanks, looking at this now.

I have taken down the public repository for time being.

This report does not describe a bug.

The staging area is a Git remote that we'll push to, so it should be a valid target for git push <url> ....

This is intentional, so you can use a task as a template to create other tasks if you have, say, several different "open" statuses. The "Create Subtask" action specifically forces the status to the default open status, but I think the current behavior is correct for bare ?template= which has been entered manually.

@paladox, you've been warned repeatedly about your consistently low-quality interactions with this upstream.

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

@paladox, your interactions with this upstream have consistently wasted our time and energy.

These things seem very general. I would expect them to be, e.g., on a wiki page like "Guidelines for Effective Code Review at <My Organization>". What advantage are you expecting to gain by building these into Differential as a checklist?

Can you give us some examples of the kinds of things you're checking for? Specifically, things where rote human review is the best solution to implementing a check?

This is the only difficult blocker for T7673, a bad behavior which is annoying and sort of user-hostile, so I'd like to at least plan our way through it.

I am going to merge this into T7303, which is a slightly narrower task describing OAuth access to Conduit.

The workflow to set a password on an account which does not have one is:

I think there's nothing actionable remaining here. Both our and Facebook's modern instructions encourage users to whitelist redirect URIs.

This report doesn't have enough information for us to move forward or resolve it. See Providing Reproduction Steps for help with writing complete, self-contained reproduction steps that we can follow to reproduce an issue.