In T13224#243817, @epriestley wrote:

@nochum, if you want to try replacing 'pygmentize ... with 'exec pygmentize ... near line 25 of PhutilPygmentsSyntaxHighlighter.php and that fixes it, I'll upstream it. exec will stop dash from leaving an sh -c process running.

Worked perfectly!

(Also: the time limit should be 15 seconds, not 15 minutes! If you're seeing the sh processes die after 15 minutes, something else is likely afoot.)

Yes, it's 15 seconds, I misspoke.

It seems the commit didn't fully fix the issue. When pygmentize runs for phabricator, there are processed that are forked from the initial process that are still never killed and they cause the cpu to spike. For example, when running into this issue on our install, we see something like:
#ps aux | grep pygm
user 13190 0.0 0.0 4456 680 ? S 16:46 0:00 sh -c pygmentize -O encoding=utf-8 -O stripnl=False -f html -l 'bash'
user 13191 0.0 0.0 4456 784 ? S 16:46 0:00 sh -c pygmentize -O encoding=utf-8 -O stripnl=False -f html -l 'bash'
user 13192 74.7 0.0 23996 9336 ? R 16:46 0:05 /usr/bin/python /usr/local/bin/pygmentize -O encoding=utf-8 -O stripnl=False -f html -l bash
user 13193 76.7 0.0 23636 9028 ? R 16:46 0:06 /usr/bin/python /usr/local/bin/pygmentize -O encoding=utf-8 -O stripnl=False -f html -l bash

FYI, I think this upstream issue with pygments addresses this issue (was open since 2016, but only recently had a commit made to fix it): https://bitbucket.org/birkenfeld/pygments-main/issues/1257/infinite-loops-in-specific-files

Fixed with: ./bin/repository rebuild-identities <repo>

This seems to have caused exceptions for us when parsing commit messages like:

In T4190#199608, @epriestley wrote:

(But note that it's cached for a trillion years, so it won't work for build status.)

Does the {img } thing work yet? I've been trying to use it locally but have not been able to get it to actually show an image. This would be super useful for us to be able to show the build status on a remarkup page (like the README.MD of our repo, for example). Thanks.

In T4181#133830, @kaismh wrote:

I have created an upstart service for Ubuntu 14.04 LTS. Create a file /etc/init/phd.conf and save the following:

I was not able to use this script in any of my installations, it always causes bootup/shutdown to hang and does not properly start the phd daemons. For some reason, phd for me has been very difficult to get up and running with upstart scripts. Whatever I do, calling service phd start always results in just a hang. If anyone has any insight into how I can do this, would be greatly appreciated. I'm running Ubuntu.

I'm pretty sure this is fixed now with the Edit Related Objects menu awesomeness! Thanks.

arcanist is not a practical tool for some of us (we use hg and patch queues), so we do the annotation manually. Is arcanist considered a must-use for phabricator?

I don't understand...there's no requirement per se for a commit to have a diff attached so the commits come through with no diff attached. Usually this happens in error because the use doesn't enter the diff id correctly or misspells "Differential Revision" or complete forget to add it in, etc. So the diff is there and was properly reviewed but the association hasn't been made.

In T10920#173847, @eadler wrote:

2. It would help if you could articulate the "benefit in having commits and diffs cross referenced outside of just autoclosing the diff". See https://secure.phabricator.com/book/phabcontrib/article/describing_problems/

@epriestley Any idea why the issue in my previous comment would be happening? Thanks.

Btw, we just ran into an issue where the Differential Revision wasn't parsed because the newline was just a LF, phabricator seems to require CRLF. So the git log shows it on its own line with the correct syntax but the description in the differential itself shows it all on one line. Another oddity...

With --keep-members parent, the child's members will be wiped out. If the child is becoming a milestone, nothing else happens. If the child is becoming a subproject, the parent's members are then copied to the child.

Would be nice to be able to skip --keep-members altogether and not move the members over at all. Thanks for the script!

Just to clarify on your last question: I wanted to be able to do "Members of: Department A". I guess my idea of putting the members on a random subproject is the way to go for this (and I think that's what you are suggesting). Also, it's not strictly a matter of security, we use it for visibility purposes too (like when a user opens "Projects" we'd rather show them those that are relevant to their department by default and have him manually search for others).

It's mostly a control thing, I can't think of any real world dangers. Eventually we plan on having even more limited access groups (for external users, similar to this installation) where there would definitely be a concern, but that may not have anything to do with this task.

Typically the latter (Department A can see Department B's stuff but not edit).

When I say subscription I mean membership. We use projects as the top-level partition for all different "departments" that use Phabricator. So say Department A has a project B and project C in which the entire department should really be members, they now have to add the members to both project A and project B. Unless I am not understanding this fully. Ultimately we use project membership in permission/membership entries for tasks and other areas (like queries/dashboards) specific to each department.

My .02 fwiw: It would be nice if there could be members of a parent project (which will effectively mean that they are members of all subprojects) so that users don't have to subscribe to each subproject individually. Maybe just as a "default membership" list that copies to each subproject since membership of a parent project is now deemed to be a union of all subprojects...

@epriestley Can you reconsider this request now?

The reason we'd rather have it on the same line is because most hg clients (including Phabricator's Diffusion, but more importantly our local TortoiseHg clients) only show the first line of any commit in the pushlog. For us to get to the revision number would require an extra action. We generally try to keep our commit messages to one line for this reason. Additionally this was something that was difficult for us to figure out as it is inconsistent with the rest of the linking functionality explained in T5132.