D17687 should dirty the cache properly on username changes. It should promote to stable within the next ~12 hours, and deploy to Phacility production about 24 hours from now.

I was able to resolve the issue by deleting my user's ssh key, and uploading the original ssh key material as a new Phabricator sshkey.

See also somewhat-related task T12397.

I still had this problem, in a fresh install. Had to run

Use diffusion.repository.search or phid.lookup to map repository identifiers to PHIDs.

I'm going to merge this into T11314, but I don't want to hard-code rules around specific names used by GitHub/GitLab. We can provide more tools to manage these refs, but I don't think the right tool is a bunch of hard-coded rules. These refs are real refs which exist in the repository, and Diffusion should be able to represent them. A driving use case for the original change was a desire to expose Gerrit refs.

@avivey Implementation of T8092 is eagerly awaited, I am merely proposing a stop-gap solution of hiding the diff and base tags listed on the Diffusion UI for a repo when the same repo is being used as a staging area.
This would greatly reduce the UI clutter and allow teams to use tags as an effective version tracking solution.

Yeah, the long-term plans are "automatic staging areas", which are essentially some kind of hidden refs (Probably using T8092 though, not just hiding stuff).

(This isn't related to the "Search" application, even though it's about searching for things.)

@dreadlord2203 indeed, hiding those tags would be useful. I found one problem with using a separate repository for change handoff, and that is access control. If you maintain several repositories with different access controls, then you would have to duplicate each of them and maintain a second set of access controls for the corresponding staging repositories. This is a lot of extra work and it would be easy to make a mistake and leak the staging repo to people who shouldn't be able to see it.

@avivey I am exploring that solution as well, I was just wondering if hiding the diff and base tags is a doable solution wanted by the community by large.
We have multiple hosted repositories inter-dependent on each other, and our setup is still in its nascent stage. So I would prefer to not manage duplicate repositories until we finalize on our long term setup.

Some feedback on this for if it's ever prioritised and picked up again, we've been using this internally for an Unreal Engine 4 based game project's binary assets for about 7 months now, we haven't run into any issues. Works great for us.

@dreadlord2203: Why don't you use a different repository for the staging area?

We have been using Phabricator for a couple of months now and have configured the staging repository to be the same as the Diffusion repository. As mentioned by others we are now facing issues in identifying our release tags due to the immense clutter of the tags. With the virtual ref solution (T8092) still some way off.
Is it possible for starters to update the Diffusion UI to ignore the diff and base tags, so that at minimum the UI clutter is reduced?

Stumbled on this issue while trying to set up my first ever SVN repo through Phabricator. However got it working with the alternate solutions found in Phabrictor documentation itself and online forums(these may be obvious to regular SVN users already).

To go at my problem from a different angle: I would also happily settle for the ability to do and save a search of commits on a specific branch. (although my goal was to include commits on master from this repo and commits from other repos cause while we have a product monorepo we have other repos for tools, experiments, etc)

In fact this is totally undermining the utility of my attempt at a recent commits dashboard... the panel's window is now entirely filled with such commits from the last minute

Is there a syntax to close audits? Something like "Fixes: <commit-hash>"?

I'm going to probably re-design this page a little.

I think we could even default it to "fancy mode" without a setting, at least to start with. I'm not sure anyone will want to access the plain text mode with enough frequency that we need it to be sticky.

@epriestley this doesn't seem hard to build for a fledgling designer/intern engineer.

In T12296#216132, @epriestley wrote:

While the git ls-remote change isn't really motivated as a performance improvement, it does seem to have reduced CPU usage a measurable amount (deployed on the morning of 3/18), maybe 15%:

While the git ls-remote change isn't really motivated as a performance improvement, it does seem to have reduced CPU usage a measurable amount (deployed on the morning of 3/18), maybe 15%:

The cause of this was mundane: the daemon queue has a large repository import in it, so the repository search update got stuck behind the import tasks. Manually forcing an index update with bin/search index Rx fixed the index.

well that was a waste. lolz. 🐈

I can't reproduce this with the steps provided. Here's what I tested:

You are my hero! :)

Also, really great bug report :)

Do you maybe have SELinux or AppArmor running?

This should now be fixed in HEAD of master. I've also cherry-picked it to stable. Thanks for the report!

I think this commit in the Git upstream is probably the culprit (January 2016):

Just tried that too, and strangely: it does.

Does it work without the --?

In T12416#215813, @epriestley wrote:

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

Does this command work on your system?

$ git ls-remote -- https://github.com/phacility/libphutil.git

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

So our only option is to convert all our LFS objects into normal Git objects, increasing both our download times, and increasing your storage and bandwidth costs? Like our Git LFS objects for the entire repository total around 800MB, and without Git LFS, our build server will have to download that from Phacility every single time it does a build.

We have no plans to move this forward or enable it in the Phacility cluster in the near future.

Is this going to be enabled in Phacility soon? We just realised that Phacility doesn't appear to have it on, and this is a major blocker for us moving from our own instance to Phacility:

I'm going to put D17497 + D17498 into this release even though they don't directly tackle the issue here and I think they're slightly risky changes (mostly because git ls-remote may have odd behaviors in some cases, and we don't currently use it in other workflows). But they may help with T12296 and general cluster load issues, and the followup changes will generally be more complicated to reason about (more locking/concurrency stuff), so I think getting these in earlier spreads risk out somewhat even though they're something to watch out for in this release.

Probably bump the version unconditionally now

(For example, if the goal was to very aggressively optimize for minimizing network traffic, we could read the entire repository history to figure out which refs were ancestors of other refs first? Then we could drop those and only ask for descendant refs. But this seems crazy, since it's saying that ~20 bytes of network traffic is more costly than like one hundred million disk I/O operations?)

it has to compare "What do I have" vs. "What do you have"

Do git ls-remote (which, curiously, seems to be significantly faster than git fetch even when git fetch is a no-op).

I think T12393 and this probably have a similar set of root causes.

Specifically, from the error, since X and Y are consistent in the error part and the fetch part, it appears that this process has lost a race to another process which is doing the same fetch.

In T5029#210026, @bcooksley wrote:

Beautiful and timely fix. Thanks!

Cool, now I don't feel so bad since I know you only recently added the option 😄

(That said, my expectation is that behaviors around unreachable commits have not changed -- D17279 added the "Unreachable" option to solve this problem.)

Likely somewhere in T9430 / T10978, which rewrote a big chunk of the audit code.

That works, Im curious when this changed, as I didn't need to filter since the last few weeks.

If you don't want to see unreachable commits, use a query which hides them:

The reason I think something isn't working correctly is in my dashboard, I list recent commits, and since I updated my install a few weeks ago my commit list looks like this a lot:

It is expected that some deleted commits will import and others will not.