I upgraded a 6 month old installation to HEAD. Can it be related? Didn't experience any other issues.

What I created to test:

I can't reproduce this at HEAD. Are there more complete instructions we can follow?

Overall, the problems I currently see with watch/subscribe are:

For the sake of completeness, the root issue you described elsewhere (unsubscribes cascading into more unsubscribes) is fixed (at least, indirectly) at HEAD, after 536d3a2, which stops self-subscribes and self-unsubscribes from publishing feed stories, mail, and notifications.

I don't currently plan to remove the option

Oh, by "remove the option" I meant "remove the option to subscribe to a project if you are not a member of the project" -- that is, "Subscribe" is disabled if you aren't a project member. I don't currently plan to remove the option, although I am leaning towards making members not be subscribed by default.

Ok, I misread T6113#83548 then, assume you wanted to remove the inconsistency by removing the ability for members to unsubscribe.

This isn't the same as T6183 or T6113, and isn't expected.

T6183 and T6113 are the relevant tasks I was able to dig up. Sounds like that option should just get removed?

You're required to verify bugs at HEAD. Please update your install.

This looks much better! Thanks!

I created a question at https://secure.phabricator.com/Q261 . @tycho.tatitscheff Thank you!

@tycho.tatitscheff Big Thankss!!

sdfgdsfgSdfadsgfsdfgsef

Three out of four's not bad.

Fourth time's a charm

Third time lucky?

Attempting to close the task again.

Attempting to close this task.

This is another comment.

This is a comment.

@YouyiDev : as @epriestley says, maniphest is not longer a good way to ask for help, but you can use ponder for that.
It is a little bit like stack overflow so if your question is wide enough, you can have different answers (like one for one platform, one for another)
I already resolved something about git hosting via ssh in Q236 and Q237 !

I managed to temporarily workaround this issue by upping the limits on the blueprints, but obviously that is not ideal if the machines can't sustain that number of working copies in parallel.

I think it might be possible to cause a deadlock with limited leases even if the Expected Behaviour is achieved, approximately by devising a build plan like this:

This is expected. Please read Customizing Forms carefully.

This does not describe a bug in Phabricator. See Contributing Bug Reports for help on filing a valid bug report. See Support Resources for information on getting help with setup and configuration.

I've already did

This is my nginx.conf

This is my /etc/sudoers file.

hey guys, this is my first time commit to phabricator.

Hm, I attempted another reproduction of the issue on a clean repo, and I can't get it to happen now either. Perhaps something didn't get the memo when I untracked some old binaries in the other repos. GA and mark this as invalid, I suppose, and I'll update here if I pinpoint a problem. Thanks anyway. :\

I can't reproduce this. Here's what I did:

Aih, I'm having one of those days.

Those reproduction instructions do not describe a bug. When you change a file and add it, it is expected that it will be part of any diffs or commits.

Hmm, okay, I wrote those out in list form to make it a bit more obvious. I don't have any way to try and duplicate that here.

Please include reproduction instructions when filing a bug report. See Contributing Bug Reports.

Thanks for sharing details. I have fixed the issues.

See T10003. See T9905 for broader discussion. See the Changelog to find information about changes before you perform an upgrade.

Yes, they are getting error message as shown below,

What happens when they try?

Yes, there was some changes in map.php and I reverted to 14ae3c099c2e4ce6c706bbaa4aa9fcb4bc7d3dec. Now the issue is fixed. But no one other than Administrator can able to create new task.

6081e640b154631cfc36b4d554a75638201762cd is not a commit in the upstream. Do you have local patches?

dfsdf

Fair enough I guess, and you are right. It's just a reality check when you see your personal e-mail address pop up in a Google search... :/

Actually, even GitHub exposes unrecognized email addresses directly in the page source, which is the same behavior we have:

I don't think this represents a real problem. This information is inherently public: pushing commits to a public repository makes this information public and easily retrievable by automated means.

Guess I'll report this to them

Oh wait, I see now that the issue is in a plugin I have installed