• Source view rendering in Paste has a missing background color.

This feels a bit like a return to the era of "epriestley design", but I think it's an improvement overall:

Still needs work:

• The secret $1-2,7-9 syntax for highlighting multiple noncontiguous blocks of lines in Diffusion is no longer supported.

This will ultimately be covered by T13105.

Effectively now covered by T13105.

See T13105 for browse cases (and perhaps diff cases, eventually).

• If a file is non-UTF8, we should try the repository's "Encoding" as a default (or maybe just remove this feature).

Junk I'm about to break in Diffusion (but plan to restore):

As with @michaeloa's case above, this is a blocker to porting repos of ours over (from Gitlab EE, in our case) for testing purposes.

okay. thanks!

See Planning.

Hello @epriestley, could you please provide any update on this task?
Won'tFix or InQueue ?

Changeset rPfb4ce851c4ae: Add a PDF document "rendering" engine allows to view PDFs from the Files application. However, {Fxxx, ...} references to a PDF file in Phriction still only allow to download the file or open a lightbox with only an icon (again with a download link).

I really like this, Remarkup idea, I think there are many text based files that people add to reviews which would be easily transformed to something more readable by being transfer directly to Remarkup, even for example something as simple as CSV,

That's a reasonable point. The details of PHI386 weren't very indicative one way or another since I didn't end up GC'ing the repository multiple times. I suppose I can go GC it again during the deployment window this week and see how long it takes.

Previously, in PHI386, an unusually large repository for the same instance took about 5 hours to git gc.

Modify the PushEvent table to contain more information about locks and waits (e.g., active queue status; how long the push waited for the write lock; how long the push spent synchronizing).

Ideally, I think Diffusion, Files and Paste should all have the highlighting/encoding options and share more of the same code, with Diffusion being distinguished by having blame (and, I suppose, symbol linking) available.

I'm wondering how this should interact with T8407: Control diffusion's syntax highlighting.

It would be great if there was an ability for installations to write custom viewers for formats that are either more obscure (MIF Framemaker format), or even in house formats (.myformat)

See followup in T13105.

Okay. For the sake of 100% clarity it would be nice if the timeline story did show why the action was taken as it isn't immediately clear (unless you've read the documentation of course) why it was removed.

I'll make a note on T12455, but we might be able to render this timeline story more clearly, e.g. "X added project Y (which automatically removed Z, a subproject)" but I think this is likely fairly natural/obvious in most cases and I'm not sure if it's trivial to completely explain in the timeline.

Ah, that would certainly explain it. Sorry for the noise - when entering this I did wonder if I had missed something as it didn't make sense that a name collision would be able to cause this.

"Plasma on Wayland" is a subproject of "Plasma".

So, in my case this turned out to be a well-known issue with git --mirror and the way pull-requests/branches are set up. I was able to clean up the issue for my purposes with this one-liner in the bare repository:

I'm seeing this currently on our brand-new phabricator install. git push --mirror worked for the first repository installed, but now on the second, this is happening.

This is something we could reasonably build now, but I think we're unlikely to build it without a customer request and an actual use case. Closing until those materialize.

Sorry, the only way to influence feature development is through a support pact. See also Planning.

@epriestley Would you guys be open for a patch for this? How would you like to see this implemented in order to be acceptable for you guys?

See T13060 and T7339 for followups and additional discussion.

I think I didn't kick Apache hard enough since I eventually rammed this through with setlocale().

setlocale(...) doesn't (?) appear to work from within Apache (?).

Thankfully, it seems that setlocale(LC_ALL, 'en_US.UTF-8'); from within PHP does work, so we don't need to figure out what PAM initialization cache file Ubuntu is actually reading LANG settings from.

sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 also does not work, although this is apparently just a Perl script that rewrites /etc/default/locale for you.

Setting LANG in /etc/environment had no effect on anything.