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.

What version of Phabricator you're running? See Providing Version Information for help figuring it out.

I think it's right to leave the options there, too. Sure, it's two controls, and they don't make much sense to use in certain combinations, but it's totally intuitive (as is the parent/subtask terminology, as opposed to the blocking/blocked terminology).

Other users at my work experience this (i.e. about 40 or so developers run into this on a regular basis). It's an issue which is particularly bad on Windows. I think it's bad because process startup / shutdown is much more expensive on Windows than it is on Linux, which means "git status" runs for a lot longer.

Ran into this today on this install. Seatrched for open/close tasks with term "javascript".
https://secure.phabricator.com/search/query/qi_sDFEgnw9i/#R

I think this was obsoleted by T10003 and EditEngine.

This UI is on life support until Facts (T1562) gets built, and I don't plan to make any upstream changes/improvements.

I think this is possibly undesirable to resolve in the general case, e.g.:

Phabricator's infrastructure has evolved a lot and CustomFields now serve a smaller role than they once did -- roughly, just custom fields. Later generation stuff (particularly EditEngine) feels better factored, and has reduced the responsibility of CustomFields.

When we make a hire we can make them do this "to become more familiar with Phabricator's codebase".

Just as a note: I had this happen again on another very low-power instance (same file storage backend, encryption enabled etc), but with the latest HEAD, simply reloading with Ctrl+R after the webserver timed out the request made it continue and work perfectly. So yes, this is fixed it seems.

I think we pretty much have clarity on stuff this task was tracking:

At HEAD of master, this is now supported. There's no default UI for it, but you can get to it in three ways: