This will be supported by diffusion.search out of T5873. See also T10329.

right, I wasn't sure if it was a special case of either of those, but I figured I'd ask just in case.

Thanks!

(This is adjacent to T4245 and should be happening fairly soon -- next big-ticket item I'm currently planning to hit after subprojects/workboards calm down.)

I'm just going to co-opt this as a subtask for that piece since you already tagged it so nicely.

I just added about 100 staging repositories by hand. I hope I spelled everything right!

Doesn't making an edit endpoint that is similar to the ApplicationEditor endpoint bypass the multi-page setup (And lets people shoot themselves if the foot)? RepositoryCreateController seems to be fully transactions-based now.

Yeah, that's broadly the "think about" part in the task title -- I don't have a good answer. I'm not quite sure how to reconcile diffusion.edit with the current multi-page form.

I'm currently leaning toward this:

• Do T10366 first.
• Replace the multi-page form with a single page form (pick a VCS, a name, and policies).
• "Hosted" is sort of the implicit default, if you want to import you then add a remote URI and set it as a fetch URI.

I think that would map to diffusion.edit pretty well, but probably leave users a little lost on common flows (particularly, "import a GitHub repository") so we'd likely have to shore it up with some alternate "here's how you do this common thing" stuff in the UI.

Oh, there are also really two issues here, but only one that I think is actually hard:

1. The multi-page repository creation form, where a single form has multiple pages in a cohesive workflow.
2. The multiple small forms for editing all the other stuff a piece at a time.

I think dealing with (1) is probably hard, and the plan above would let us get rid of the multi-page workflow entirely, which is why I'm leaning toward it.

I don't have a plan for (2) either, but it's relatively easy. In the worst case, we just add all those fields (like "text encoding") as "Conduit Only" fields to the EditEngine, and leave them as separate workflows in the web UI. That's not great, but it would just cost a modest amount of code duplication, and we'd still be reducing overall duplication by a large amount.

I suspect we can do a little better than that, maybe by letting EditEngine have a concept of "sections", but the worst case isn't too bad so it's not a huge issue if we don't tackle that or don't tackle that for now.

I'm going to merge this into T10748, which has implemented these endpoints, although they won't be fully functional until we cut over to the new URI code, likely in the next week.