The behavior is not inconsistent with the documentation, and the documentation does not suggest the configuration you selected.

I was referring to T9973

This is something we've needed for like over a year or more, because we need to filter the importance of different things failing, or we explicitly want messages when things pass.

We don't take feature requests without understanding the root problem. Please see Describing Root Problems. We have many systems planned for integrations with other products, but without knowing what you want specifically to accomplish, we're unlikely to be able to actually help.

In T10274#157022, @epriestley wrote:

Where's the other request for this?

I was referring to T9973

The motivation was this scenario:

You can land onto a remote branch with a local copy of the branch which isn't really that branch but is just some other branch which you've named the same thing as the other branch.

We can't do that if we actually write onto Release1. The original task or tasks are linked from T9657. The new behavior generally remedies a large range of scenarios where users were confused by arc land writing to Release1 when they did not expect it to.

I think that makes sense for arc land, and as odd a workflow as I find it, I understand the need to support it, but arc land --hold implies modification of local repository, no? Previously arc land --hold was a legitimate workflow that put the user's repository in a very predictable and easy to understand state. Now the end result feels like some process got interrupted in the middle and is really not useful for anything other than pushing. It even kind of looks like a repository that is left in the middle of a failed rebase, with detached heads and unmerged branches. It also leaves garbage branches behind that the user now needs to go clean up manually, and since the branches do not appear merged into trunk, it needs to be a force delete, which is always a little bit of a scary operation, especially for people not experienced with git.
>

See also T8227.

I'm very much with you on that one. That's why I'm suggesting assuming a certain intent behind using arc land --hold and Doing The Right Thing(TM).

You can use arc alias to define a new command which runs arc land --hold --onto X && git branch -f X HEAD or similar.

Yeah, but that requires us to specify the branch to land onto, which is something arc already knows from .arcconfig.

T7477 is tracking this, it's reasonable to support, but not very common overall.

External.

Is the mailing list a Phabricator mailing list or external?

See also T5118.

Because I wasn't replying directly to the task email, I was replying to a colleague's response in the thread. I did not change any recipients from the default when hitting reply all. The sequence of emails went like this:

Why did you CC the task instead of leaving it in the TO field?

oh wow lol.

In T418#157090, @chad wrote:

What version of pfabricator does the following "shouldAppearInListView and renderOnListItem" parameter is available in ManiphestCustomField ?

Not sure what the context is for this question. This task is open because the feature is not complete.

What version of pfabricator does the following "shouldAppearInListView and renderOnListItem" parameter is available in ManiphestCustomField ?

I guess "impressum" is the "mesothelioma" of 2016.

What version of pfabricator does the following "shouldAppearInListView and renderOnListItem" parameter is available in ManiphestCustomField ?

Actually, I'm pretty sure @denialgorge's comment is also SEO spam!

Pretty sure that was SEO spam, not just bumbling.

My users want to send an email to the entire team when a build fails.

Isn't this a duplicate of T8982 (and of T7097 by extension)? The fix you propose has already been submitted, though it was later abandonned (see D13745).

Really thanks for you thoughts, It has no impact for me at the moment, but you know it was my 2 cents and I think you might want this kind of "feature" in future when serious and fun businesses collide somewhere in between :)

We are currently experiencing this problem on one of our repositories, but not the other 50 or so.

Where's the other request for this?

Yes, that will work.

In your first example, you can likely:

thanks

T9657 is probably the relevant guidance. There is no way to get the old behavior back.

and you beat me to it.

Sorry, I accidentally submitted in the middle of typing :)

This is not a valid Phabricator bug report. Please see Contributing Bug Reports.

I'm not planning to touch all the cases like ` #x, {nav #x, ``` #x, %%% #x, etc. We don't have a client-side Remarkup parser and I'm not planning to build one for this. See T3725#39466 for some earlier discussion.

This currently triggers autocomplete, but probably shouldn't: ` #f.

It ok no feel bad

Thanks for the report @perezd and sorry for my bad testing!

I feel dumb because in my testing I set the field to literal null and not null.

and also the culprit! hoo hoo hoo!!

@epriestley is the hero.

mine looks identical to yours (app settings)

PHP 5.5.9-1ubuntu4.14 (cli) (built: Oct 28 2015 01:34:46)
Ubuntu LTS

(also maybe helpful, what PHP/OS you are running)

/applications/view/PhabricatorFilesApplication/

Can you look and see what your limit is set to?

These files were well under 1MB FWIW.

b51a859636ac was recent, so maybe it did break something.

It's anything over 1MB.

I haven't tried to reproduce this, but the error about "store large files" seems out-of-place if the files are small.

Are there steps to reproduce this?

I had never setup anything for file storage in the past. It was never configured.
I've restarted php/apache many times, including immediately after I updated it as the documentation states to do.

If you just updated Phabricator, how long has it been and did you restart PHP/Apache?

set that field to null, and you can repro it.

set that field to null, and you can repro it. I did not get this error prior, and I should not be getting an "upload" error as I try to simply view a source file in my git repo via diffusion.