I understand a high level problem of "i get too much mail when watching a project", but I don't really have a picture of the specific "root problem". We don't really want to guess why a specific column is more interesting. Knowing the background of the project and columns might provide some insight. Maybe they need to "sign off" for instance in anything that comes into a specific column, like "QA". We just don't know, so it's hard to understand what the correct upstream solution is without these details.

I don't have any idea where further/deeper to go than to what I already described in the description:
User is not interested in being notified about all tasks of the given tag, but only on those which are in particular column.
If you ask "why", I can imagine perhaps "I don't want to be spammed by things I am not interested at".
Perhaps might yet be worth to note, that it obviously applies to boards sorted by categories/area, not progress-wise (Kanban).
I can also assume it is related to discouraging of "tracking tasks" (ie. due to many issues with task graphs) which are typically exactly equal to such workboard column - they "monitor" certain area of the project, so user is subscribed to them, but not watching the entire project.
I don't know what to add more. Better if you ask.

You should see this information about the feature request form:

@Danny_B Are you aware we don't take feature requests that omit root problems?

I ran into the same issue and phabricator-ssh-hook.sh and its parent directory are owned by root and the script have 755 mode. The script was in /root/phabricator/ and vcs-user doesn't have access to that directory (because the /root directory is not accessible). I put the script in /etc/phabricator and it worked.

Here's an effort to collect use cases for the hooks I plan to break or replace:

Concretely, I think this breaks down as a mixture of modernizations and new code:

Changes connected to T8116 implement the initial server-side version of this. It's still very skeletal, but we probably need to make some client changes to move forward. In particular, the next object to implement is probably Signature, but signature algorithms should live in the client since the client will need to be able to verify signatures.

I'm just going to consolidate this into T5055, I think they're pretty much the same task at this point.

I wasn't really sure. So I thought that "previous commit to build [...]" and "ancestors of that commit [...]" relates to the order in which Herald triggers, which must not be equal to the one in the repository. So Herald would trigger B-A-C and the build step Wait for Previous Commits to Build just ensures that they are processed sequentially. But regarding to your comment this was obviously a twisted thought of mine. :D

Given my description, what other behavior do you think it might have?

Thank you very much for your fast answer! What about the order? Does Herald/Harbormaster ensure in this case that the builds are always processed/triggered in the right order? I mean if there are three new commits A-B-C in branch develop pushed, is A build before B is build before C?

If you have the ability to edit a diff, you have the ability to edit a diff and it's relationships. That seems the simplest, most straightforward way to describe the way permissions work here.

I expect, that I can a) don't add commits etc, no matter, if I press the button at the task nor at the commit for example, or b) I can do it at both ways.

(T11357 is a companion issue for Files.)

D16323 uses <input type="text" pattern="\d*" />, which appears to have the best behavior.

On iOS 9.2 in the simulator, <input type="number" /> gives you this keyboard:

Oh, there's a "Toggle Software Keyboard" option that I somehow disabled.

On iPhone Simulator, the behavior of <input type="number" /> appears to be "draw the keyboard for 1 frame and then immediately hide it".

Looks like an iPhone with Gboard keyboard.

Offhand, do you know if <input type="number" /> has the desired behavior on your device?

In broad terms, well, you've got a good product and vibe going on and I guess I'm not the only one asking myself "when will phab have feature x and be able to do feature y". Being more transparent in that way could help better promote phab and even win more users over just by seeing what you're up to. It's easy to get addicted to your progress and to see exciting new stuff regularly.

I've not looked into the details of the implementation you started, but because it's gettext I thought maybe some links wouldn't harm:

• https://blogs.gnome.org/mclasen/2016/07/21/using-modern-gettext/
• http://nedohodnik.net/gettextbis/
• http://laxstrom.name/blag/2013/11/20/review-of-gettext-pot-file-format/

What behavior do you expect?

@epriestley Why? Actually I think this is confusing.

I would like to add, to anyone browsing this and trying to get a new instance of phabricator working on php7, to not do that (since it isn't supported and is now blocked by the software itself).

I recognize as a user (and a developer myself) the situation and that, as a user, I'm just complaining and not giving solutions. I also recognize you don't want to be dual-developing phabricator on multiple fronts. We're running on arch so I'm extremely biased AND recognize that saying this isn't a workable solution but because of the "bleeding edge" php levels on arch, I would prefer focus on php7 (again, super biased and I know that isn't just going to happen).

What would you like us to do differently?

I think what is most frustrating about this is, having fought through php 7 configuration (without opening tickets, just trying to follow other tickets and doc), after an update today I'm greeted with having to edit source now to get php 7 (unsupported, I know) to continue working...

This is working as intended.

Did you run into this on a local install or this install?

Thanks :).

File a bug report please.

It didn't work for me.

Isn't this more or less the same issue as arc set-config needs to update either local or global configs?

In T11364#186934, @epriestley wrote:

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

@epriestley Because it allows the reader of this report to reproduce the underlying issue without cloning anything or clobbering their .arcrc. Here are some less contrived scenarios, which are not mutually exclusive:

• the user makes a typo (project lacking .arcconfig, or trying to use Phabricator for the first time themselves)
• the .arcconfig comes from a time before Let's Encrypt (e.g. if you're in the middle of a git bisect that takes you back some distance)
• the admin is just attempting to migrate people to more secure services and does not expect that services will fail (or at least not fail in such an opaque and confusing manner) in the face of a redirect

This looks closer to a server configuration issue to me and is actually a pretty strange behavior (mostly because i'm not sure how the redirect after it looks like a request is served works). If I go to http://secure.phabricator.com/api/user.whoami in the browser i get the following

{
result: null,
error_code: "ERR-CONDUIT-CORE",
error_info: "You are trying to save some data to Phabricator, but the request your browser made included an incorrect token. Reload the page and try again. You may need to clear your cookies. This was a Web request. This request had no CSRF token."
}

as expected or maybe not? However if i run curl http://secure.phabricator.com/api/user.whoami i get

{"result":null,"error_code":"ERR-INVALID-SESSION","error_info":"Session key is not present."}

Why are you running arc install-certificate with a manually entered URL?

arc upgrade: Upgrade everything? This feels sort of bad/dangerous, maybe? But maybe fine? We could prompt?

I guess you're right. We've never really questioned the behaviour of these GUI tools. We assumed that because they do this automatically and provide no way to disable it "they'll probably know what they're doing".

Part of the tension here is that any package-related command potentially has two targets: arc itself, or the current working directory (Phabricator, some third-party app you're developing, etc).

None of that really does anything yet, but the next steps (signing, installing) need to have major components in arc, so I'm going to consolidate this into T8115 / T5055 and other related arc work.

(We could detect this case and fail with an error, but the root issue here seems to be that tracking is being set on a remote branch which the local branch really does not track.)

Generally, I'm very hesitant to use "will the push change anything" as a signal, because I think this is unintuitive and will create confusing false negatives. Specifically, if you do this:

Have you asked Sourcetree or Git Tower to change their behavior instead? They can compute ahead/behind without setting tracking, and it seems like setting tracking is not really correct here (the local branches do not really "track" temporary remote CI branches in the traditional sense).

I'm not sure actually. Most of us use GUI tools like Sourcetree or Git Tower, which automatically set up tracking when a branch is pushed. I guess they do this to be able to show the "Commits behind / ahead" badges on branches.

Why does the local branch track the remote branch? Do you push using --set-upstream? If so, why?

I see the same behavior noted by @lianghu in T9042#129510.