I've contacted Atlassian about this. They told me Sourcetree tracks branches automatically to cope with git's push.default setting. By default this is set to 'simple', which means git will push the current branch to a tracked remote branch that has the same name as the local branch.

No problem, thanks for the report!

I just did a Ctrl+Refresh and it looks correct. Sorry for the dupe (I searched "gradient" but didn't find that revision).

I think this was resolved by D16381, I just didn't deploy it until a moment ago.

In fact, this also happens with other panels. Basically the top right panel will always be duplicated to bottom left.

i can confirm

This reproduces for me as described.

D16385 increases the storage length of the underlying column. Summaries will now be cut to 255 bytes or 80 display glyphs, whichever is shorter.

This also happens with integers and epochs:

We truncate these summaries at 80 bytes because the underlying storage column is text80, which is only 80 bytes long when represented using binary collation in older MySQL without utf8mb4 support. We can not store more text in the general case without changing this column size.

I was experiencing this problem too and it works in current stable for me now.

Also, your steps to reproduce contradict your description.

Can you reliably reproduce this each time? Can you post your version information as required?

This document may also be helpful in scripting Phabricator commands:

The Aug 19 2015 reply from James Day in https://bugs.mysql.com/bug.php?id=66546 gives me some hope that MySQL may adjust behavior here. Although that comment is now almost a year old, it responds to a comment from about two and a half years prior, so this may actually be fairly new in MySQL timescales.

I think this is the corresponding MySQL bug:

Oh, yeah that's probably a fair point. @epriestley ?

In T11433#189141, @chad wrote:

mysqldump is not a phabricator command.

mysqldump is not a phabricator command.

In T11433#189037, @chad wrote:

Can you point to me exactly where we state you should build a cron? https://secure.phabricator.com/book/phabricator/article/configuring_backups/

I think this should be fixed in HEAD of master now. It should promote to stable pretty shortly, probably. Let us know if you're still seeing issues after updating, and thanks for the report!

That's perfectly fine. Thanks for the thorough answer! I see your point and indeed, I think this strikes a better balance.
Keep on doing this great work and building a product that helps everyone have fewer bugs! ;-)

I'd theoretically be open to doing that kind of thing, but I worry it would waste a lot of our time in arguing over whether or not something is really a good bug report or not. We already see a lot of this with our security bounty program and the definition of a valid report there is very narrow.

Thanks!
Evan, do I get an extra free month for using phacility?
;-)

I think we already add this flag in most cases (via ArcanistGitAPI->getDiffBaseOptions()), but the specific check in arc land doesn't go through that code (since it doesn't really care about the diff, just if the are any changes at all).

Thanks Chad!

Looking at the history of git, it looks like --no-ext-diff was introduced circa 1.5.3 (2007).

nice!

A better way to think about this is, we only want Phabricator specific things in our documentation. Once an item falls outside of Phabricator, our expectation is you will manage that based on your preference / expertise. Unfortunately with a team of two people, maintaining a greater level of detail in the the documentation is significant and insurmountable.

Can you point to me exactly where we state you should build a cron? https://secure.phabricator.com/book/phabricator/article/configuring_backups/

In T11433#188778, @chad wrote:

It's not our intention to provide detailed examples for every scenario or operating system, given the tens of thousands of possible examples needed.

It's not our intention to provide detailed examples for every scenario or operating system, given the tens of thousands of possible examples needed.

They should be symlinks. As git represents both symlinks and the executable flag, it should be unnecessary to chmod them.

I actually encouter the same problem. Setting autoclose on master only fixed it.

Reproduction steps are required for all bug reports. How can we reproduce the error you are seeing?

Yeah, T7447 is probably the best source of discussion about this.

There's lots of discussion about this in T7447 and related T1460.

$ php --version
PHP 7.1.0beta1 (cli) (built: Jul 25 2016 13:58:06) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies

That might explain it (not sure how I got on the beta, wasn't aiming to). I've switched to the 7.0 version, will see if that fixes it.

What PHP are you running? I seem to recall an issue with one of the brew packages.

The reason we require it upfront is that it's a large support burden to ask for this information. It costs Phacility money. If users provide it upfront, we spend less time on support and more time building Phabricator. If you're a frequent contributor, this obviously compounds and make providing support even more cost effective. We just want to be able to provide everyone with free support. See also T9212 for longer discussion.

I don't know if this is a bug report or feature request. It's missing information for both. Please read and follow Contributing Bug Reports and Contributing Feature Requests for how to file stuff into the upstream. How can we make it more clear this information is always required?