Weirdly, another server restart fixed this for me.

As I've understood the EditEngine supersedes CustomFields by the flexibility. Are there any examples (in code or in documentation) on how new fields can be added to commits or other entities?

I think the big trick on this is going to be making inline comments work somewhat-correctly in the extreme case of octopus merges.

This also seems a little hard to believe to me, at least in terms of being a general flaw with this workflow:

the auditor may spend a significant amount of time before even realizing they've already looked at the changes.

You're not wrong ;). I'm mostly referring here to a scenario where a significant enough time has passed where the auditor might not remember the individual commits (months), so the list of merged commits doesn't provide too much value. The user then would have to click on each one to see if they reviewed them already, and then still try to figure out if htere are any additional changes.

I'm going to close this as "Wontfix". Although adding custom fields is something we may still do, I no longer expect to "rebuild" on top of that infrastructure.

No. This task covers documenting this syntax.

Is the information from above (T5132#69200) also available in the documentation in this comprehensive form?

Thanks, D17218 should fix this.

The form still does nothing useful, but it's not a default any more

Having recently installed and configured Phabricator for our work environment, we need to host hg repos with largefiles in it, so we can't wait for this ticket to be completed. Feel free to ask if you need some testing, as we have no development capabilities to offer for this project.

I'm going to close this since the original use case seems to have not panned out. We're still open to building this, but would like to see a modern use case driving it -- feel free to file a new request (or leave a comment here) if you have one.

We probably would not use an option to turn the feature off (versus just supporting it) so don't worry about adding it on our behalf. At the point where I was set up to convincingly test that turning the feature off worked -- and we had navigated bundle2 in some way -- I'd probably be most of the way toward proper support anyway.

Heads up: Mercurial 4.1 (to be released ~February 1) introduces media type negotiation in the HTTP protocol. https://www.mercurial-scm.org/repo/hg/rev/753b9d43ca81 captures the wire protocol changes and the commit message explains why things are done the way they are.

I'm going to merge this into T7076, which discusses revisions instead of commits/audits, but the resolution for both is likely the same and that task has a more complete discussion of context.

I'm going to merge this into T9430 since they have the same upstream remedy. This query has largely been modern for some time, but I want to sort out T9430 before providing diffusion.commit.search.

Ah, cool. I'll throw something hacky over this for now if I have a chance, then.

I started redesigning the main header last night, don't expect it to land before stable cut this week. I'll probably land it all at once. (Header Redesign + Favorities Menu).

I think the item didn't exist at all before, and T11114 created it as a side effect. All the installs I have immediate access to are up to date, but, e.g., neither the KDE nor WMF installs have "Create Diff" or "Create Revision" in the menu even though I have access to Differential on both.

Before the menu item seem to be called Create Diff and it worked. Right now it's called Create Revision and clicking on it shows an error:

Actually, I think this is a separate bug, moving to MenuItem, it's still broken there as well. Probably related to T11114

Although I earlier (in T6630#85282) felt like it was reasonable to consider separating Audit and Diffusion, there are now more existing or planned integration points and I think this approach is significantly less reasonable than the "merge them" approach. It also doesn't seem to be causing any problems on real installs.

Some parts of KDE use git notes fairly extensively for certain specific workflows.
How difficult would it be to have Phabricator permit pushing Notes, even if Phabricator itself didn't do much with them (doesn't need to display them)?

Ah ok I was just thinking that if anything happened to be depending on the state of the working copy then removing the -u argument could affect those.

The other side of the Conduit call still issues an hg (or git, or whatever) command in most cases, but sending everything through Conduit means a different host (one which actually does have a working copy) can give us the answer if necessary.

They shouldn't interact -- T10753 is mostly about clustering. When Diffusion and the daemons need to ask questions about a Mercurial repository, they're supposed to issue a Conduit call so Phabricator can get an answer by asking another host if it needs to. In a few cases, they currently just issue an hg command, which only works if the repository is present (and up to date) on local disk.

This might depend on T10753?

乁༼☯‿☯✿༽ㄏ

I'm just going to merge this into T9548 since I think bundle2 support will fix it?

I'm going to merge this into T5815, which is a more general discussion of action queues.

• DiffusionCommitQuery has had the "good" version for a while.
• We're nuking Releeph at some point.

Thanks for the report! We were just missing a "/" (Quicksand does not follow redirects, which I think is desirable, although maybe we'll change that eventually) but D17151 should fix this up a little more robustly.

I believe this reproduces by following the steps in T11537#192019, but deleting all timestamp information completely.

I think "Autoclose" is likely getting updates in connection with T12010 anyway, so work there may obsolete this.