@epriestley Can you reconsider this request now?

What I created to test:

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

Does the user exist in Phabricator?

It can also happen when you configure stagging with ssh and you let the repository beeing clone with ssh and https !

Thanks Evan that was a great help. I have got that configured and working but how can i get it to send an e-mail with the ticket details to the person who submitted it?

Yes, it was because the SSH agent wasn't running (on Windows). I would have preferred to have it error and not submitted the diff, rather than having to do "arc diff" a second time to get the diff pushed to the staging repository.

Flags currently has this unwieldy dropdown, which will only get worse over time as more applications and object types are added. It would be better to use a typeahead, like the one in global search:

I removed this because the implementation was pretty hacky (saved the rule as a text string, wasn't translatable).

good enough for me

@chad, not sure if you have design thoughts here, but I think this is broadly reasonable.

I think it's too hard for us to guess user intent here. There's nothing a user can do which strongly signals that their flag is obsolete, since flags mean a lot of different things (in your use case, it sounds like there's no single action you take which clears the flag, just "the next action after you added the flag"). Other users (myself included) use flags for different reasons, including as long-term bookmarks. Guessing intent is also difficult because you can flag many kinds of objects, not just tasks, and we'd strongly prefer features which can be implemented globally.

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 would make flags actually useful. I think the last time I used them was years ago, and I've just been adding comments to tasks whenever I need to add personal reminders.

This looks much better! Thanks!

Mmm I didn't know that existed - will be super useful. Sorry for the bogus
task.

@dgoldstein, also, for future reference the way you find the list of email commands is to open an object of the type you care about (here, a task), click the circle/lifeboat thing, and then click "email commands."

@epriestley Is there any capacity to get this Prioritized?

T4027 is another case of commits titled [JIRA-123] Blah blah blah.

This is very old, possibly fixed by now, doesn't include reproduction steps, and other users haven't reported issues. If you have specific issues with externals and reproduction steps, feel free to file new tasks.

This is extremely old and I think no longer relevant. The crumbs now show the current branch, and I think Diffusion got better about consistently showing and retaining branches.

T5744 mentions another narrower and more reasonable use case (get specific badness which matches some pattern fixed), which is similar to the Mochi/i18n stuff.

T5046 has a specific case of this causing particularly questionable behavior when doing HTTP clones -- since the object is totally hidden, you don't get prompted for credentials.

This is expected with Spaces, which completely hide objects (primarily as a performance consideration). I'm going to merge this into T9771 which discusses this issue more broadly.

T8296 is a similar case for "Add Mirror".

I am still trying to find a solution to this, but until I do I am considering hosting the SVN repository outside of Phabricator.

This behavior is not expected. Please file a bug report with reproduction instructions.

We don't make or support git-phab. If the only reason for needing a new feature is because you're using a new, unsupported 3rd party application, it's not something the upstream will have any ability to prioritize. We prioritize tasks by likely impact and adoption across all our installs.

Back at work... I have the same php, php-curl, and php-json versions in Cygwin and I am still core dumping (with my questionable-or-worse distribution system I'm not sure what arcanist and libphutil versions). I then updated to arcanist b3e68c9 and libphutil adb8a9c and arc doesn't seg-fault anymore. So, it seems to me that the initial trigger has likely been removed from arcanist but the issue that made it a seg-fault instead of a nice stack trace I suppose is still there in the PHP packages.