Ah, there are really a couple of issues here.

Come on, Evan, seriously? :-/

Please please please please please please please please please please please please read Describing Root Problems carefully and think about what it is asking for.

In T11312#188006, @Danny_B wrote:

there is no (preferably customizable) real feed (Atom, RSS). [...] there was some task here about it but I can't find it now.

A small (partially off-topic) note about feed - in such a high traffic Phabricator instance like ours (WMF), it is nearly unusable. Fortiori if there is no (preferably customizable) real feed (Atom, RSS). Lack of feed support in Phabricator is one of its biggest disadvantages. I know there was some task here about it but I can't find it now.

As I was asked to provide some input here:

In T11312#187893, @epriestley wrote:

• Why aren't they using "Send me an email" rules?

That is what I am currently doing via Herald in our Maniphest installation. :)

• Why aren't they using Feed?

As a bugmaster, my workflow is primarily email-based (describing a fact here that likely could be challenged). I receive notifications on Maniphest task changes which interest me and filter / process them. I abuse the "Unread" status of certain emails to mark stuff I'd like to follow up on later. I have not played with Feed (or an application to consume feeds) to be able to judge whether that would also suit my needs on processing large amounts of information and acting on some of that.

• Why do they want all of this information in the first place?

As a bugmaster, I'd like to get informed of most / nearly all changes on tasks, to allow me clarifying task descriptions (steps to reproduce etc), escalate issues that seem important, manage expectations, etc., to support our many stakeholders.

That looks broadly correct to me, I just want to try to remove the assumption that the first object's first field's storage is universally the right storage in fixing this upstream. It's always true today and for the foreseeable future, just obviously not a Fundamental Axiom of the System. Let me review D16346 and I'll spend 10 minutes on this, I'm pretty sure it's straightforward, not a weird snowbally mess, and that the upstreamable patch is only cosmetically different from that one.

This is brittle but it works if your objects all use the native storage.

I think the issue is that there's no callable thing for bulk-loading custom fields right now, which is why SearchEngineExtension doesn't have a hook for it. Other SearchEngine extensions don't need it since none currently load any data.

T10635 is vaguely related, too.

See Planning for help understanding timelines and priorities.

I can't reproduce this here, locally, or in the Phacility cluster. Can you? You should be able to push to rGITTEST on this install, or launch a test instance from admin.phacility.com and create a repository there.

Is this still actively being worked on, is there a different solution than View Options->Set Tab Width, or should I apply the patch referenced by raman.rathod?

It would probably help if I knew what 'refs' git was trying to push and failed on. Normally git is meant to tell you what failed if I read all the git pages/help - but it seems git isn't telling me anything about the failure!

Thanks for feedback so far :)

(ノಠ益ಠ)ノ彡 sboן ʇsǝʇ ʇıun

Yeah, unit messages are stored in a different table.

Is this different than T5822?

You should check if the user has write access to the folder where the repositories are stored. It happened to me (I wasn't using Phabricator). I can clone because I have read to access but can't push because I didn't have write permission.

This is not an expected behavior.

(I'm not super adept at troubleshooting git, so I can't help much more on this question).

I don't believe we alter your commands, it should be a direct passthrough.

It is definitely a git error - but if i use git to access the repostory directly on the hosting server (clone it from the actual stored repo path) that works fine, and I can then push ok with no errors, which leads me to think git is working ok.

This is a git error, isn't it? That is, if you're not using Phabricator to access the repository, the same error occurs?

I'm going to close this in favor of T10448, which discusses fixing "other" tags and generally improving how tags work.

I think custom forms (today), workboard support for custom forms (likely, in the future), and T8442 are the most promising ways forward here.

It's still not really clear to me what this issue is describing. Here are my best guesses at how to fix various things which might be problems?

T7961 is probably worth fixing while I'm in here.

I'm going to at least fix the instanceof mess before adding a Calendar adapter in T7939.

Calendar is currently prioritized, but the scope is focused on basic functionality (getting it out of the "prototype" stage, roughly described in T11326 with more recent activity in T11326) and API integrations (Google Calendar in T2334, ICS in T10747).

I'm just going to close this in favor of T10038. The short answer is: write bindings.

I expect to do this eventually, but I'm hesitant to just put a freeform "Location" text field on events. If we do, we can't prevent double-booking physical meeting rooms, since users may spell physical space names differently and we can't know for sure that "Meeting 6", "Meeting Room 6", "Meting Rum Six", and "Meeting Room#6" are all the same.

Not claiming it's better (it seems to do a lot of what arc lint does, minus the ability to amend), just that we already have linting set up through it and have custom linters implemented in that framework.

This isn't a valid bug report. Valid bug reports include reproduction steps, version information, and if there is a log or error message, the exact message generated. We also don't have access to third party installs. We'd be happy to re-open this report once missing information and steps are filled in.

Does overcommit emit patches? I'm reading through the docs, and not clear what the benefit specifically is over arcanist. If it's ease of distribution, we're actively working on that.

@oujesky thanks for the git link. I was able to get the arc patch command working in the meanwhile with these changes.

How can we make the title and description more clear?

Hi Chad,

(We've not heard any similar issues like this, unfortunately).

See Support Resources for how to get general community help with Phabricator. Thanks!

We don't take bug reports without reproduction steps and we don't support older versions of Phabricator.

any customization.

Does this ticket request include displaying Status of each Task on the Workboard display?

Thanks for the report, and for including detailed reproduction steps which allowed us to reproduce the issue.

See T5447 for information on reusing Phabricator code in third-party applications.

It sounds like you're running an out of date version of Phabricator. Please update to the latest version and see if the issue reproduces.