https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ covers a little bit about us and requesting features too, if you're interested.

Those settings are for the import process, so people don't get hit with 10's or 10's of thousands of emails.

In Diffusion → Project → Edit you already allow notifications to be disabled on a project basis, which would accomplish this. On the other hand, it also includes killing the feed and herald.

We don't plan on letting adminstrators at this time set settings for end users. We may at some point, but strongly feel at this time it's a user preference. You can simply write a script if you like and alter the MySQL table directly.

Ah, sorry. I'll retitle. This would be a global/repository setting request

/settings/panel/emailpreferences/ then under Audit.

./phabricator$ git rev-parse --short HEAD
6d5aec8

Is your install at HEAD?

Side note: Specifically the use-case here is that we're hosting on GitLab and already get commit emails. I could see how it would be a bad idea, but maybe if your repo is "Hosted Elsewhere" diffusion could default to disabling email notifiers and make it opt-in?

@epriestley, that repo is stuck at 99.99% importing now...

I still think that timestamping the feed events in the phab DB based on the timestamp of the commits in the repo is ideal here (although I don't know if it's feasible).

We don't do a good job with this workflow right now:

Don't forget about pestering you!

The Phacility reasoning here is that administrators don't have access to daemon logs and I'd like to avoid giving them access, so there's no way to figure this out on your own except by guessing.

(I changed this to https:// and it's now importing.)

Maybe turn off feed notification during import?

Found this, missing piece was clicking "Update Now" to queue an update message.

D11789 ended up taking care of all of these.

I'm not 100% sure what "blame revision" actually means, but current "mentioned" transactions might have solved this issue?

I might be able to give this a go.

Looks like it's more "5% of a diff":

Let me see what I can dig up, I think I accidentally declared branch bankruptcy at one point..

@epriestley, what's your half-diff do?

Arcanist projects are deprecated. Symbols should move to be repoaitory-based.

It would also be great to be able to see all the commits in a range, e.g. master@{1week}...master. (Comes in handy when writing changelogs.)

Aside from hg push --force you can also push multiple heads when using bookmarks, if you use hg push -B my-bookmark

Okay, so... I updated and that didn't help, but what did help was the realization that diffs are only included in (Herald rule) "Commit Hook: Commit Content" emails, never in "Commits" (i.e. push) emails even with the inlined-patches setting enabled. That means I'll have to send out multiple emails for pushes with multiple commits, but at least it works now. Thanks for helping out!

Thank you @wokuku I haven't had the time to find out what was going. But I followed your suggestion and it is actually that what I also noticed is that in the branches screenshot there are several branches for default when in reality there should only be one.

(Oh and we last rebased on upstream on 2015-01-07)

So the daemon log is 17G so grep is a bit slow

I can't immediately reproduce this -- I get proper 15-second waits between clone attempts.

You can push them with hg push --force. For hosted repositories, we additionally flag such changes as "Dangerous", so you have to enable "Allow Dangerous Changes" in the repo settings or we'll stop you. See D7763.

I had this same issue, but there was only one not-closed default branch. Maybe just not show closed branches?

Yeah, this is not quite the same as T7085.

I could get around the problem by setting my default branch to something other than "default", as suggested in the other task. But the "default" branch is really our default branch and i would really like to show changes there as default.

In T7085#93884, @chad wrote:

@wokuku let us know if this isn't correct for your issue.

@wokuku let us know if this isn't correct for your issue.

SELinux is currently disabled (until everything else works, then it's that project).

Do you have SELinux installed? It's hard to get ssh working if so - see T4947.

Go to Diffusion → Choose a Repository → Edit Repository → Branches → Edit Branches and set a different default branch.

Your right. I should have done an upgrade before anything else.
That patch solves the issue.

I remember having to do something else for this to work. Unfortunately i can't remember what :(
The feature works fine for me.

Restarting Phabricator hasn't made a difference. Will play around with it more tonight to see where things are still going wrong. Thanks for all your input, it's much appreciated :)

Changing config values should prompt you to restart the webserver/daemons.

Hm, I just pushed a couple of small changes to master and the commit email still only showed the summary. I had metamta.diffusion.attach-patches set to true and and metameta.diffusion.inline-patches set to 5000 (which should be more than enough for the few lines that were changed). The ones for metamta.differential were also set accordingly, although I guess that shouldn't matter as it didn't go through a code review in this case.

Yeah I think this should be moved to personal settings, not sure if there is a technical reason not to.

Yep. try setting both.

Oh wait, I set it for Differential but not Diffusion. Let me verify that it works and I'll close the bug after. Thanks!

Good point, I actually seem to have set that setting to 1000 before. However, none of our commit emails ever seems to include patches even below that number of lines. Maybe this has been fixed since I last updated our Phabricator instance?

There are config settings for this already. Take a look at metamta.diffusion.inline-patches (which sets the maximum patch length inlined).