@avivey interesting! Will investigate, thank you :-)

T5793; Global rules can set/remove projects/tags from tickets - this can keep you afloat you for now.

I just ran into a fun issue that @avivey helped me figure out,

I've been avoiding those tools as compiling our project for .class files requires a lengthy amount of time, which would be better integrated into our jenkins test runners.

Derp. I'll check it out.

thanks! :)

It does require .class files - I run it in the CI along with the tests (And PMD).

I added you to Community if you want to do the honors. :)

Ah, ok. sorry! This was a local issue. But now I can't close this task...

what test console?

Have you tried the test console?

I can't immediately reproduce this, here's what I get:

I promise I searched first! Thanks for the info

To be clear: I was trying to describe my problem, not ask for a specific solution. EditEngine for creation would help a lot but I was focused on editing. I guess T10337 would actually solve the issue, though not in the web UI.

I thought FindBugs required analysis of the .class files which I didn't think would make useful for linting, but perhaps as UT or something?

Since only the first connection has an issue, you could also conceivably add a slightly-more-than-one-line patch to make arc land run some no-op remote operation (git remote show origin?) and then immediately kill the subprocess, creating and throwing away the bad connection so the followup doesn't hang.

If you're open to patching one site, you can just comment out the feof($stderr) to retain the bulk of the change (i.e., still wait for stdout).

I can sort of see arguments either way, although I think I'm inclined to names too.

Using SSH master connections has two advantages:

1. Connections are indeed faster. In a minimal case (SSH'ing to an adjacent machine on the same network), it reduces the time for a no-op SSH connection from 0.14s to 0.01s. The utility of this grows as one needs to tunnel SSH connections in order to access a machine; for instance, SSH'ing to our Phabricator instance requires bouncing through a bastion host; using SSH master connections reduces the time to connect from ~0.7s to 0.01s. This is notable since arc may produce mulitiple git commands which attempt to fetch from upstream.
2. Authentication information is preserved. If the connection does two-factor authentication, for instance, the user may be supplied with an authentication prompt when the master is set up. Re-using the master preserves this authenticated session, and reduces the amount of re-authorization that the user must do.

I would go for Space Name personally.

Change milestoneNumber in phabricator_project.project to reorder milestones.

Is sorting by Space ID (instead of Space name) definitely your preferred sort?

This is unintentional, I only meant to hide archived projects on workboards. They're incorrectly behind hidden in all contexts.

Sorry, I'm still not sure I quite understand the specific use cases for this feature that you anticipate.

so the relation with the project can still be identified after moving the task to a different space

See also T1279#42118, T9372, T10031, T8080, T6596

The benefit of enabling ControlPersist is only very slightly faster SSH connections, right?

We have 2 distinct profiles and a few one-offs.
Ideally the following would be managed: Policies, Text Encoding, Branches, Actions. The remainder are templatized but obviously differ from repo to repo.

Do you legitimately have several distinct "profiles"? What differs between them?

In T9897#151198, @epriestley wrote:

Couple of thoughts, not necessarily unbeta stuff:

• Now that I'm actually using Phame, figuring out some kind of monogram/remarkup thing for it would be sort of nice so it's a little easier to reference a post in tasks/wikis/etc (my use case is that when I write a "Development Log" or "High Horse Soapbox" post, I'm often providing context for things elsewhere, and want to link it from that place/places). I don't think actual POST123 monograms are great for this, but this motivate:

@20after4 It would be helpful to get a sense of what your ideal tree looks like -- would adding the immediate parent project always be sufficient to disambiguate things? Or would it produce 30 different projects named iPhone > Bugs because the full hierarchy is CrazyFlaps > iPhone > Bugs, FlappyFish > iPhone > Bugs, etc? Or do you have a mixture of hierarchy depths?

Maybe a config option to make your own regex for display? Or just a select of a handful of options like

If the parent is already a parent project of some other project, it has no direct members, so nothing will be copied. --keep-members parent should do what you want, provided you move "Members" first, before "Subproject A" or "Subproject B".

This is covered in the conversations above, but the short answer is: There are 16 possible levels of subprojects, so there isn't any clear path forward to us guessing what you want displayed, and thus it is up to you to name Projects accordingly.