ひらがな
漢字汉字

漢字
汉字

Great! Handling of branches is definitely something we'd like to improve in the future, but most of the improvements we have planned require significant amounts of work. If you eventually run into limitations with this approach, hopefully we'll have some improvements in place by then.

I can confirm that the solution works properly. Once again, thanks! :-)

Thanks for the suggestion. I'm trying that now.

Er, that wasn't even close -- this is simpler and actually works:

I think you could do something like this (made-up pseudocode because my bash is garbage):

We routinely have multiple commits on multiple branches because we mirror (via Harbormaster) our master branch to an experimental/master branch. This is safe because the two branches are never touching the same paths.

• PhabricatorSyntaxHighlightingConfigOptions defines this option.
• Change the type from wild to custom:SomeClassName to switch to a custom type validator.
• The new validator class should subclass PhabricatorConfigJSONOptionType.
• You can look at PhabricatorKeyringConfigOptionType for a (more complex) example of how to validate a value.
• Test by trying to change the value to something invalid, you should get an error.
• You can test a regexp is valid like this:

Cool. We'll improve this in the future and make it easier to find once we do.

this will work just fine, thanks!

This is essentially complete except for the Google Cloud specific issue with MyISAM being unavailable; I'm going to retarget it for that.

If nothing's been typed in the text field for more than 5 seconds the user probably wants memes

Thanks, much appreciated! 👍🏻

@chad thanks for sharing your perspective - I will try to share positive feedback as well. Hopefully that will allow the constructive feedback I have to be considered, as I have felt like the feedback and ideas I have shared have often been dismissed or had a very harsh response.

Users can customize their search (like I have below) or you can fork Phabricator to provide a different experience.

Your feedback is continually negative and tone deaf.

@chad I am trying to give constructive feedback to improve the product, including both the pain points and suggested improvements. I am not used to this kind of response to product feedback. It's unfortunate.

You've made it quite clear on multiple occasions Phabricator is a painful product to use for everyone at your company.

Our interest / problems related to this persist. I haven't been vocal as I don't know what else to do other than to share my feedback, but I continue to hear negative feedback internally in our company regarding this issue, per the description above.

Crazy, I guess I'm in some project called ? ?

("We don't want to do that just to make Phabricator work" is a completely reasonable response, but at least in this project this practice seems useful and we'd probably keep doing it even if branch information was more accessible.)

This is somewhat difficult because querying which branches a commit appears on is slow (in some cases, extremely slow; see T9898), and it is difficult to cache because a small write (pushing one new branch) can change the branches that millions of commits appear on. For example, if I do this:

Can you unhide the event please so I can fix my notifications?

Well now I have 4 notifications I can't see or reset. :(

Yeah, the user is struck through because they are "closed", which is because they are a bot. This isn't the best way to deal with this, but it dates from early 2014 (D8231) when everything was simpler.

Ah I missed that sentence above, this is why the bot user is disabled:

Mailing list and bot users are also considered "closed" because you usually want to hit normal users instead of them.