This appears to be resolved and accounted for. There's one followup in T11120 (8bit vs base64 mail encoding) which also might be fixed now. If anyone runs into issues, let us know.

I believe this is now resolved and accounted for. See the remarkup documentation for some details.

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

I believe this is now fixed and all the business stuff is wrapped up on our side. If anyone runs into issues, feel free to file a followup describing what you're hitting.

Sorry, my screenshot was garbage since all the text to the right was INCREDIBLY CONFIDENTIAL SECRETS.

Oh, on task view, I was looking the edit page.

Isn't Badges a Prototype?

Yeah doesn't repro in Chrome.

FWIW, examining every ref like that is a complete no-go for our situation

OK, so I just manually removed the branch from info/refs and packed-refs and I think that maybe that worked?

I think D16136 will "fix" the problem and I can't come up with any problems it creates, although it would be nice to figure out where the mystery ref is coming from.

okay so basically ghosts?

In T9028#180932, @joshuaspence wrote:

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

I think checking if git ls-remote origin in the working copy lists a refs/remotes/origin/XYZ ref in the authoritative remote is the easiest way to check, although I'm not 100% sure that refs/remotes/ isn't magic with respect to ls-remote.

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.