I wonder if the actual authoritative repository has a refs/remotes/origin/XYZ ref which we're mirroring?

We fetch bare working copies with git fetch origin +refs/*:refs/* --prune.

In T9028#180926, @epriestley wrote:

Hrrm -- is the repository a non-bare working copy (e.g., has files and folders in it instead of just config/, hooks/, info/, etc)?

Is there a lack of a git remote prune origin or similar?

Hrrm -- is the repository a non-bare working copy (e.g., has files and folders in it instead of just config/, hooks/, info/, etc)?

OK, running ./bin/repository discover --verbose rX gives me a bunch of output including this:

We have Diffusion configured to track only the master branch, but now Diffusion is importing commits from all branches, it seems.

Updated our Phabricator install just now. One issue I discovered is that we are having a bunch of audits triggered for commits that are newly discovered. We have Diffusion configured to track only the master branch, but now Diffusion is importing commits from all branches, it seems.

I updated my original answer (since I can't post a new one; I meant to add it as a comment on your original Q) with instructions on how to write the Herald rule you need, so you can accept that answer as "the accepted answer" for this Ponder.

We're basically having lots of problems with Windows; There are a few reports about arc version just not working on Windows (I'm a little surprised @hach-que doesn't run into this; Can you maybe do a quick phriction page about your Windows setup, as in "this setup works, do this"?).

Yeah. I just wanted to make sure whether mark-reachable was safe to run without fear of accidentally marking something unreachable that isn't (i.e., if the command were to imply "mark everything in the import queue as unreachable no matter what"). Sorry it was probably a bit of a lazy question since a more careful re-reading of the rest of the ticket would probably have answered it for me.

It basically runs git log --all, then checks every commit in the database against that list and marks the missing ones as unreachable.

If the mark-reachable command is used, is it subject to races in the sense that in-flight legit newly importing commits may be marked unreachable, or does it just trigger the process of going back and re-evaluating true reachability of all commits?

I've pushed this here, and enabled dangerous changes on rGITTEST if anyone wants to try anything.

Your best workaround for now is multiple text panels for each organization.

T11161 is the follow up for Dashboards

I'll create a separate task to re-think Panel creation UI.

You're not creating a custom query, at least in that screenshot. The query is "All Documents", which is what you're getting.

I think this is resolved, but see T9028 for related followups.

I'm vaguely suspicious that I may have missed some weird stuff here since this pipeline is complicated, but I'm going to land this stuff now and just plan to hold the release a bit if it feels shaky tomorrow.

Can anyone interested in this explain the use case for making it per-Herald or per-user instead of global? Are half your users bitterly opposed to inline diffs, even after we fixed the Differential ones to not be terrible (T10694)?

I'm going to merge this into T9028. Specifically, daemons should be able to permanently fail operations on unreachable commits after D16131. That task discusses deleted/unreachable commits more broadly.

We can't reproduce this, so we can't move forward. Feel free to open a new issue if you are able to provide reproduction steps.

There don't appear to be any major outstanding issues here.

This has seemed pretty stable for about a month. Future work is tracked in more specific tasks.

This fix appears to be holding.

I'm going to merge this into T9028. Specifically, D16133 rebuilds the summary table after any commit becomes unreachable, which should produce the correct commit count and other summary details.

black-listing phabricator/ sounds good to me :)

D16134 just hard-codes phabricator/ tags as untracked, which should minimize collateral damage.

Yeah, the actual rule D16129 implements is this:

In T6878#180701, @epriestley wrote:

For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future.

oh wow

they are mine T.T

i can has arts

We could do posts too, but I only have 3 arts so far, so blogs seemed easier to start with.

Oh for blogs, not posts.

Is this an example of "title art" or is there something better. I seem to think there was an actual header, but maybe not.

OK, Feature request filed here: T11158

I've deployed this and configured this server to use AES-256-CBC, although I haven't retroactively migrated existing data.

fair enough

We don't feel it's a good use of time to build out hypothetical features. The main reason is you're asking us to build something for a case that's never happened, and may never happen. We'll always likely have something more impactful to spend our development time on. Even taking this as "Wishlist" essentially means we'll never get to it in a reasonable timeframe.

I'd like the UI to not offer things which don't work - I have not tested Mercurial and SVN hosting and given that I've done nothing to make them work I imagine they don't

Is this actually a problem or are you just anticipating users will do this?

We can't reproduce this and haven't seen other reports of similar issues (including from other installs of greater size and complexity), so we have no way to move forward on this.

Bookkeeping; there's no longer an external driver for this.

Just bookkeeping; this doesn't have an active external priority driver.

Just bookkeeping, this doesn't currently have external priority.

Pulled and working! Thanks a lot!

This should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.