https://secure.phabricator.com/book/phabricator/article/support/

I created the task, then changed the tags manually (selecting only the tags I felt necessary - also removing the BUG tag). Seems I may have found a bug with the bug tracker. ;)

That is, if you go to the Diffusion workboard, we give you a generic create form instead of a choice between the various normal create forms, currently.

You can file stuff without those tags from workboards, and maybe "Support Request" just got caught in the crossfire of typing every possible tag, so that's a legitimate-albeit-unusual pathway here. But I wouldn't expect the short-lived "New Support Request" form to be accessible any longer.

This tracker is for bug reports and feature requests, and we're surprised you were able to file something without either of those tags.

How did you file this task?

Ah nice.

We have logic to determine the repository already (you can see it at the user-facing level in arc which, for example). You should just be able to remove projects completely, I believe.

@epriestley, do you have any idea how Differential would work without Arcanist Projects? My only thought is that we could do some sort of Conduit call to determine the repository. Probably this should happen server-side I guess.

Things that still use Arcanist Projects:

We haven't seen other users having difficulty with this.

base_uri breaks lots of random things, which is why we ask you to set it (though some people use it fine without, in limited ability). The full setup message also states scripts and daemons will likely have issues.

The text shown in the unresolved setup issues was "The base URI for this install is not configured. Configuring it will improve security and enable features." - I would expect it to tell me that this needs to be set up before I can import a repository, not silently fail in the background.

Closed by commit rPd2ea0bc5f0df.

This extension will help with the mapping of old vcs aliases: https://github.com/make-all/libphalias

I've got desired effect by adding my code into custom Harbormaster step, that I've attached through Herald to be executed on new commits, see T6518.

Ah, I didn't knew that recent dates are shown in different format.

July 8 was a long time ago, so we use the "a long time ago" format.
Nov 9 was a few days ago, so we use the "a few days ago" format.

It's ok, that format was changed. What I consider a bug, that different formats coexist in same list. If you do store parsed date format in DB, then why this wasn't fixed by a migration?

We change formats for dates that happened a while ago, under the theory that you don't need to know the year for recent events and don't need to know the weekday for events that happened long ago.

Before you've replied I've tried to implement this locally and I was very surprised when all demons at once picked up the work and PhabricatorRepositoryCommitParserWorker::doWork method was executed 5 times. Is this normal?

1. Before you've replied I've tried to implement this locally and I was very surprised when all demons at once picked up the work and PhabricatorRepositoryCommitParserWorker::doWork method was executed 5 times. Is this normal?
2. There are no protection inside to prevent such things from happening, like daemon who wants to parse the commit locks that commit, which should prevent others from doing the same in parallel.
3. Is there other (non-event based) way to do custom code after commit is parsed? If so, then where this code should be placed?

We don't plan to implement this. We generally intend to move away from events: they're too complex for most users and we've found better approaches in most cases for most reasonable use cases.

I'm running into this problem too, with Mercurial 3.1.2 (with Python 2.7.6) and phabricator 3463ce8a514f87287cd961ded284e60153e851d8 (from Fri 3rd Oct).

hg heads -c --template "{branch}\n" | wc -l

Support Impact Substantial effect and unclear next steps.

Support Impact This has cropped up a number of times and is surprising and broken.

We hit the issue too.

Any ideas how to fix it?

Assuming that explanation covers things, but yell if stuff is still unclear.

If you run multiple copies of the daemon, it's expected that they'll occasionally fail to acquire locks, because another copy of the daemon is busy updating the repository.

I might have been, yes. Is this not supported?

Closed by commit rP53a678c56823.

• I think T5771 fixed some of this. At least two of the reports fell under that umbrella, and it was the least obvious reason for autoclose to fail.
• Issues related to commits not importing because of emoji or non-utf8 encodings are covered in T1191 (and maybe T4045). This task will not resolve them, and there is no real workaround until T1191.
• I'm not fixing the (presumed) original issue here, where message reparsing didn't unstick the "not on autoclose branch" flag. At some point in the future I'll move scripts/repository/reparse.php to bin/repository reparse and add a --force-autoclose flag to cover this. I think the behavior is correct in the general case: if a commit did not autoclose when initially imported, it should not autoclose when reparsed (there are a bunch of reasons to reparse that are not related to autoclose). This is filed in T5966.
• Other stuff in this task should now be more reasonable to debug. If you're still having issues you can't figure out after D10348, file separate tasks or come hunt us down in IRC and we'll walk you through the new stuff.

I'm getting the same error as OP. It looks like the folder for the created repo is owned by root with drwxr-xr-x. If I chown the folder to my phd user, I can push to the repo.

Closed by commit rP6f246bd35190.

I think that plan ^^^ is a pretty good one, and this crops up somewhat-often.

T5938 has a very similar issue on Git 1.8.5.5. I'm at a loss as to what's going on there, but hopefully the fix for this will fix both.

◀ Merged tasks: T5938.

In T5896#7, @epriestley wrote:

Do you have ~10,000 branch heads or bookmarks in this repository?

Do the branches shown in the web UI make sense to you? Are they obviously wrong?

Trace: {F192790}
I tried Phab with CentOS7 and python 2.7.5 and hg 2.6.2 on the same repo, and have the same result
In branch history there is offset 1100, so it's near this number of branch heads

http://phabricator/diffusion/F/branches/default/?offset=1100

But

[root@Phabricator F]# hg branches | wc -l
221

And there are no bookmarks

Specifically, I think this issue is related to the enormous length of the command. The command is supposed to look like:

Do you have ~10,000 branch heads or bookmarks in this repository?

Can you run the command again with the --trace parameter specified?

Are you running multiple copies of the PullLocal daemon?

I hit this same issue when trying to use PhabricatorGlobalLock inside Drydock, which appeared to only occur with lots of frequent requests to Drydock. I ended up using beginReadLocking instead, but obviously this is a problem that impacts existing code as well.