I want to also stress that the new interface does not communicate the different options available very well. The old wizard had radio buttons with things like "have phabricator host your repo" and "host your repo outside of phabricator".

In T11335#186091, @avivey wrote:

Can you configure gitblit not to expose these refs, ...

Thanks hach-que . I get remove php5.5 reinstall php5.6 and its running ok .

Maybe I shouldn't debug things before coffee. getChanges is fine, the problem is something else; I think the recorded information might be wrong.

Not a rendering bug, it's a translation: https://secure.phabricator.com/diffusion/P/browse/master/src/infrastructure/internationalization/translation/PhabricatorUSEnglishTranslation.php$1571

Mostly, that's because getChanges in PhabricatorCalendarEventInviteTransaction is wrong - the phids in this transaction are in keys, not values.

Just wanted to chime in that I've just encountered this as well. Just did an upgrade, and hundreds (possibly thousands?) of old commits are somehow being reprocessed and are pushed to the feed. It's been processing for a couple of hours now, no idea how much work remains....

T11335 talks about a hosting system (gitblit) that adds meta-data to refs/meta/ refs, which show up in phabricator as real commits.

Can you configure gitblit not to expose these refs, or have phabricator observe the github repo (Assuming these refs don't make it there?)?

It appears that trackOnly really does only apply to branches and not refs

Since there doesn't appear to be a way to reproduce this at HEAD, we can't move forward.

In T11335#186057, @avivey wrote:

You can configure the repository track only value to not track refs/meta, which is apparently where gitblit records it's reflog.

In T11335#186057, @avivey wrote:

You can configure the repository track only value to not track refs/meta, which is apparently where gitblit records it's reflog.

Phabricator is looking at all refs, and gitblit is recording some information as refs, which interact strangely.

It's a little concerning that gitblit doesn't host it's own code, instead relying on github. Regardless, I haven't yet found a public gitblit repo that I can point to for reproduction.

I have not been able to reproduce in phacility, and moving tasks around in our current install works correctly.

In T11333#186012, @chad wrote:

We require bug reports be reproducible by the reporter under our basic "free support" model. The basic idea is it's better if you spend 1-2 hours than us spending 1-2 days guessing the problem though back and forth questioning.

One thing you could do is test a current version of Phabricator with your steps on http://phacility.com with a free test instance.

FWIW, there are the transaction logs (via conduit) for a task that was experiencing the issue.

There may be some extra steps here, but I think this covers what we did. Unfortunately this spans several months, and I'm not in a position to setup another install and walk through this to test.

In T11333#186009, @chad wrote:

For example, 11.9.0 sounds like a Milestone, not a subproject. Is that correct?

For example, 11.9.0 sounds like a Milestone, not a subproject. Is that correct?

What are the minimum set of steps on a new, clean install we can follow to reproduce the error your seeing locally?

Did you mean to file this as a feature request?

But I still kind of think that if you generated a link to your own content you should be able to navigate to it, so it seems reasonable that either:

• remote URI that start with pre-configured base URI are considered valid
• "View Raw File" generates a local URI relative to base URI to avoid this check

I guess I can phrase that differently, then.
Consider that this services as an exception and the associated error message is extremely confusing:

• It specifies a URI that is valid and is not external to my server and calls it both remote and invalid, which is odd
• The URI that is surfaced is a long and very internal-looking one, clearly generated by Phabricator itself
• There is no explanation given as to why this is considered invalid.

This isn't a bug. List HTTP and HTTPS if you want to use these protocols.

Upgrade.

Thanks for listening to my hair-brained schemes. Yeah, the motivation is totally clear to me FWIW, and thinking about it more, I strongly suggest this is related to T9161.

Thanks for looking into this further.

Looks like that fix affects Differential, but not Diffusion? After reading through that bug, I can totally reproduce this on demand in Audit
I have a test instance here that reproduces this problem (both actively able to reproduce and has commits in the database that are exhibiting the behavior already): https://test-kdauzhhtarbi.phacility.com/rLIBdde2f74f2793f0216f0d76618ed335a9c802cfec, but I reproduced it reliably on 3 separate instances now.

I've marked D16287 as fixing this, although it does not fix Countdown (today, only Calendar has the new behavior).

Sounds similar to T11092, which was recently resolved.

Needs a check for empty and at least a better error message in DiffusionBrowseQueryConduitAPIMethod.php:115

We are seeing this as well when attempting to browse an empty commit: https://phabricator.wikimedia.org/T140236

I'm unable to reproduce on a test install right now, but then again, I stopped reproducing on my install after rebooting the server. It looks like something happens eventually to cause this to break and I start getting these broken comments.
Looks like every time I get a broken one it doesn't have a transaction PHID associated with it and all comments submitted together have the same wrong associated commitPHID.

oh neat!

You can use a free instance at http://phacility.com/ if you need a clean, up to date place to test privately.

This is, by the way, on a brand new install that's not even a month old.
I tried to reproduce it on another install that is older and I'm not having any luck.

This actually is a lot worse than I originally thought.
All inline comments that are made on an audit are actually applied to the audit I was previously commenting on (like an off by 1 error). I've isolated the following things:

• This happens across repositories (i.e. if I have multiple repositories, commenting on one commit and then switching to another repository's commit and commenting on it will produce a comment on the first commit)
• This happens for all users
• This happens regardless of audit status - i.e. commits with audit requested exhibit this as much as commits that don't require audit.
• Submitting an empty comment first thing before adding any content to a commit works around this problem - subsequently added commits appear as expected.
• The broken state can be easily detected by unavailability of the "hover state" of the overall commit field - pressing "z" does nothing

(Presuming that fixed things until we see evidence otherwise.)

Indeed, fixed.
You guys rock!!

Specifically, this should be resolved by D16242 (July 6).

Can you update Phabricator and re-test? I expect this to already be resolved.

It might be reasonable to un-pht() the field names in the short term until this gets solved for real, although it would be nice to see a use case with a legitimate translation rather than Pirate.

This is sort of very vaguely related to T5586, although I don't know if the fix will end up being the same or not.

"Spies" should get picked up and parsed as "Subscribers", just like "Fixin'" should be picked up and parse as "Fixes".

We tend to combine similar issues into one so they are resolved at the same time by the same diff. The correct solution I believe here is the same as "magic words". That we need to maintain a list of words that are localized that trigger actions. "Spies" should get picked up and parsed as "Subscribers", just like "Fixin'" should be picked up and parse as "Fixes".

That's correct, there are no magic words in my diff message. The template I'm given when I create a new diff contains text (I assume because of the Pirate language setting I've chosen) that causes Arcanist/Differential to choke when the message is committed, as "Spies" isn't a valid heading in the Diff message.

I don't think this is about "magic words" - those are things like Fixes T123. This is about "regular" l18n: Differential is producing a form it can't read.

Alright, that's promising at least. Thanks for testing!

In T11291#185175, @epriestley wrote:

It's possible that we're in the wrong by falling back to set character set utf8;.

For anyone who can reproduce this, does this fail?

mysql> set character set utf8mb4;

We could also possibly just drop these commit mails in all cases where no audit triggered. It's easy to write a Herald rule to restore them if you do want them. Possibly involved enough to be adjacent to T10978, though.

A small part of the motivation for this change was to make commits reachable only from Gerrit magic refs (refs/changes/..., similar to refs/pull/...) visible in Diffusion. This didn't really make it into a single upstream task I think, but some of this is scattered across T9726 / T6878. So we have at least one use case where users want these refs to exist and be treated roughly like they were tags/branches.

If it becomes a persistent problem, we will update the documentation.

Do mention that on https://secure.phabricator.com/book/phabcontrib/article/version/ .

We don't have the capability to support every user who uses Phabricator to file bugs directly into the upstream. Users also don't have the means to update their local instance before filing a bug, which we require (we only support the latest version of Phabricator). Users can also use http://phacility.com/ to reproduce bugs.

Maybe they can get it out of one of the HTML comments inside one of the pages.