Closed by commit rARC7bde5941cf71.

I have a diff awaiting code review that should fix this.

I'm pretty sure our install is running into performance issues due to this as well.

Thanks, I forgot that Aphlict worked that way. That would definitely be causing a fair bit of traffic for us (probably more than Phabricator itself). I'll try turning it off and see what happens.

Thanks, I forgot that Aphlict worked that way. That would definitely be causing a fair bit of traffic for us (probably more than Phabricator itself). I'll try turning it off and see what happens.

With regards to git and %B, it definitely seems that %B is more desirable than %s%n%n%b. We could default to %B but fall-back to %s%n%n%b if the git version installed doesn't support %B (and probably raise a setup issue saying that "git version x.y.z is recommended").

The line breaks in my case are all single line breaks. Maybe @epriestley can shed some light on what is the expected behaviour?

This isn't quite the same as T5028... What I am asking for here is that all remarkup (whether it be commit messages or READMEs or whatever else) be

I may not understand the issue here, but I can't replicate this issue. If I view a commit in Diffusion which has linebreaks in the commit message, then I see linebreaks in Diffusion as well. I'm going to reopen T4813 because it is not quite the same as this.

Closed by commit rARCec3de41684c9.

I think the first approach seems to be reasonable and probably not too difficult. Not knowing how the underlying (JavaScript) code works here, I feel as though if the "save draft" action is queued at some time X and the comment is submitted at some time X+Y (Y > 0) then there is no reason to store the draft.

Closed by commit rPHU4b85681758d7.

Based on D8682, it seems that the bug was related to not writing transactions. If this is the case, I guess that the graph would still be wrong for historical data, but I should expect it to be accurate in the future. Is this correct?

Ok, so after updating everything earlier today this problem still exists.

Our error logs aren't quite working at the moment. I'm in the process of moving Phabricator to a new dedicated host and don't really want to investigate where the logs are going until then.

I get this exception when trying to edit the existing key: Object of class PassphraseCredentialTypeSSHPrivateKeyFile could not be converted to string. I think its a permissions issue.

My particular pain point at the moment is running arc lint --everything, which probably isn't a common use case. The last time that I ran this over our code base (which is quite large) it took around 20-30 minutes. We have more linters setup now so it likely takes a lot longer.

Ok, so D8971 didn't fix this, at least not completely.

Closed by commit rARCf2b341ae038a.

Yeah, ok... that sounds entirely reasonable. Let me give it a shot.

Will D8942 actually fix the exception? Or just prevent the application from getting into this state?

Yes, we use this linter on our own code base, which seems to be a reasonable use case.

Sorry, I meant that after performing arc upgrade (i.e. after upgrading libphutil), it may be necessary to run build_xhpast.sh, not during arc upgrade. This would be the case if the user wishes to perform arc lint with the XHPAST linter after they have upgraded.

Correct me if I am wrong here, but it's not true that the build_xhpast.sh script is a developer only feature. Any user of arc who at some stage performs at arc upgrade will possibly have to deal with this script.

Was it D8682?

Oh ok.... do you know when it was fixed roughly?

Ok sure... where should I be looking in the DB?

OK, thanks for the update.

I think this example works: https://github.com/jenkinsci/job-dsl-plugin/blob/master/README.md

Yes, that is essentially what I am asking for.

@epriestley, any thoughts on this? I'm happy to work on a fix but I'm not 100% clear on what the issue is.

Ok fair enough.

OK, I can provide some more insight into this.

It was (and still is, partially) unclear to me under what conditions a file would be syntax highlighted with pygmentize. It seems that the following logic is applied:

◀ Merged tasks: T4746.

✘ Merged into T4767.

Hmm, ok. So I ran ./scripts/repository/reparse.php --message --all X, but the diff is still in the "Accepted" state.

So I've now marked the repository as imported... is it possible to reprocess these commits so that the diffs are closed?

Ah! Right, okay. That would explain it.

Another potentially useful detail is that the repository is only 99.99% imported. This is because 1 commit could not be processed (I had to kill the worker task) due to the commit message containing a UTF8 character outside of BMP.

This is probably related to T4746

Thanks, this works

No, this doesn't seem to work. Although I'm talking about autoclosing diffs, not maniphests.

What I mean exactly is that I have a differential with the following properties:

This is partially a duplicate of T4720 (which doesn't including closing diffs)