so that error and this one:

Still occurring. :(

Also cc @epriestley in case he's more concerned about this generally than I am...

Ah, thanks. Is there any way to re-run the original operation that failed here from the cli?

Cool, and if its still occurring it will be top of my queue again. :)

Will check it ASAP in the morning.

Alrighty folks impacted by this - could you please update your Phabricator install, including re-starting daemons, and let us know if the issue is resolved or you're still having problems?

okay, I kind of get how come it happens at least. that's nice.

I get this tracking Phabricator on my home install.

...still working on reproducing this... if anyone has a public repo I can clone that reproduces that issue this would be helpful.

This is a mysql configuration issue / scaling issue. See something like

@chad - what remote are you tracking that reproduces this?

Ah okay, I got the link to load. Its going to take me a few hours to figure this out so I'd stop importing those repositories for now if its driving you batty.

the phab.met.no link doesn't resolve for me - should it?

I see this on my local install tracking a remote as well.

Re: the last point. I'm also seeing this for existing employees at the institute, who have submitted commits using e-mails different from the ones that they are registered with on the site. I haven't noticed this for anyone else - the problem seems to be limited to commiters who are not registered on the site.

Yes, you are right, I've cloned the repo yesterday, but I hadn't updated it yet.
My mistake, sorry. Do I change the state to Resolved or Invalid in this case?

Is your instance up to date? This should be resolved .

Was about to create a new task for same thing for SVN working copies.

Another +1 from me. Would it make sense to just ask the submitter for a revision to use as the base?

Now has a solution to this problem?

Closed by commit rPd9dd098e405b.

Closed by commit rPd9ad4ab385c2.

Yes, it's a known issue.

Seeing the same thing on this instance:

That did the trick. Thanks!

Ah, okay. Thanks! I'll get a patch out later today pr early tomorrow.

Oh, I notice I forgot to mention it was about a task :/ My apologies for
that.

(This didn't reproduce on this install just now. See D10712 and corresponding commit rPac83ff706023e266907ed625954ef9b988daf014 )

You have a very old version of Phabricator. Try updating.

Can you show me a raw commit message involved in these shenanigans?

I've now seen the same issue over several commits, leading me to believe
that it's not a fluke.

I am not reproducing this in my test environment.

Nice catch.

Well, it should have worked there...

Closed by commit rP3dd92a78ac2a.

Seems like I've found a problem. There are filenames in CP1251 encoding, but Phabricator tries to parse them as UTF-8

In T5646#69864, @btrahan wrote:

I dig the bigger picture plan.

This is a very low priority because there isn't much interest in any specific extension.

Our project is a game with lots of graphics. As we plan to move from SVN to Mercurial, it is a limitation that Phab does not support Largefiles (which is a must in our situation). Though I'll try a patch from T5189 as temporal solution.

We plan to resolve this eventually but it's not a priority. SSH does not have these scalability limits and is the recommended workaround for large repositories.

We've hit the

The same error happens in differential, when you have a renamed file. You get the message "This file was changed only by adding or removing whitespace. Show File Contents", and clicking Show File Contents throws this error (in core.pkg.js line 333).

Specifically, the commit message summary is never processed as a transaction, so user/object/file mentions don't activate. This also means @user doesn't CC, and {Fxxx} doesn't adjust permissions.

We added mentions recently. The merge was correct. See next transaction for an example.

Ref is for maniphest tasks... or does it work with differential revisions as well?

Ref currently does that job, I'm just wondering if we should make Ref action the default anytime an object is referenced anywhere (instead of via a comment mention).

Hmm... maybe not a mention, but I feel that there should be some sort of relationship.

Maybe @epriestley can weigh in too.

Oh, maybe I am misunderstanding your description. I do not expect an object in a message to count as a "Mention", only a person actually mentioning it via a comment box.

This feature to my knowledge does not exist.

• After T4767, some debugging information is available in https://secure.phabricator.com/book/phabricator/article/diffusion_autoclose/.
• After T4036, mentioning an object in a comment somewhere else will add a "<user> mentioned this in <thing>." note to the mentioned object's log.

In T2999#78548, @altendky wrote:

The first time you commit a good (UTF-8) file it will still list as binary because the old side of the diff is binary. The second good commit will result in a good new and old version that can be text diff'ed. Also, pure ASCII is not needed, UTF-8 is fine so you should be able to use whatever characters you need for your native language.

The first time you commit a good (UTF-8) file it will still list as binary because the old side of the diff is binary. The second good commit will result in a good new and old version that can be text diff'ed. Also, pure ASCII is not needed, UTF-8 is fine so you should be able to use whatever characters you need for your native language.

Ah, I think I know what is causing this issue then. It says that auto-close is not enabled until the import is complete. For some reason my repo has been stuck at 99.98% finished for several days.

Same problem with our assembly files (working directory on Windows7 disk folder): is not possible to view them in Audit because they're seen as "binary" (while they are visible as diffs in Differential probably because unix diff we use fixes encoding). Verifying their nature with cygwin 'file' tool they are seen as:

My bad, missed that document!

It's expected to work with commits.