I'm going to merge this into T10366. After D15822, this information is available via diffusion.repository.search by asking for the uris attachment. Note that:

Try that one instead.

Actually, this doesn't behave well with very long titles. Let me see if I can find an alternate fix.

Thanks for the report. This should be fixed in HEAD of master, and should promote to stable within 24 hours. Let us know if you run into anything else.

Can you point us at where in the UI these are used, exactly? Just want to make sure we're fixing the right thing.

This is the expected method.

It has the visible effect of removing the page header and footer.

The heuristic only triggers if the repository was previously empty. So it might possibly get a false positive on the very first pull request to a new empty repository, but should be fine after that.

Note that when you do this, you may generate a large amount of email you don't want, because you're adding commits to a repository which was previously marked as fully imported (it "completed" the import process when it was an empty, hosted repository). You may want to disable publishing in "Publish/Notify". See also T9554.

I can't reproduce this. Here's what I tried. First, I created a new, empty, hosted Git repository:

If you know the ID/monogram of the room (should be in the subject of any email you received, looks like Z123), I think you can also bin/policy unlock Zxxx it, which should make it public. Then you should be able to rejoin it.

@benjumanji, I added you to Community so you should have some new powers to abuse.

Great, I'm glad to hear things are working for you. Thanks for your help testing this out!

Oh, the actual implementation would be --revision (with a short option), I was just using --the-revision-for for clarity (or extra confusion?) in discussing the meaning/behavior of the flag.

Some earlier discussion in T5781, although I didn't really have a clear way forward at the time and still don't.

This should be fixed in Week 17. See T8952 / D15773. Let us know if you're still seeing issues after upgrading, or can reproduce the problem on this install.

we'll get to it when we feel like it (ok not a totally fair paraphrase, but it's one way to read it)

Perhaps helpful for context is T6027, which was open for longer than this (about 18 months).

What isn't helpful about it? I believe it has a complete answer to your question, and a great deal of detail explaining why that's the answer. How could it be more helpful? Did I misunderstand what you're asking?

I suspect this isn't a bug -- diffs have repository associations, and you must be able to see a repository to see associated diffs. You must be able to see the active diff to see a revision. So andy caused the active diff to belong to a repository that nuno can not see, which prevents nuno from seeing the revision.

I'm going to merge this into T10748, which is now more clearly the way forward.

See Planning for information on timelines and progress.

I'm going to merge this into T10748, since that's now clearly the way forward.

I'm going to merge this into T10748 because that's clearly the pathway forward now. You can view the new UI at /diffusion/X/manage/, although it mostly doesn't work yet and there are no links to it in the UI.

T10751 and T4292 are reaching a steadier state now and have some indirect/soft dependencies on this (for example, the new panel for monitoring the cluster status of a particular repository is part of this new UI) so I expect to drive this forward at least somewhat in the next few days. I'm not sure how ambitious I'll feel about meddling with the URI code before the release cut, but there's a good chunk of basic work remaining before that becomes an issue.

See also Contributing Bug Reports:

The instructions are correct as written, and are aimed at being as simple as possible for users who may not be familiar with PHP. We can not possibly include instructions for every imaginable installer, see also T4200.

In particular, the install instructions tell you to:

How did you install PHP, exactly?

Yeah, measuring latency and using it as a signal is tricky. If there's a long disruption and Oregon measures faster than N. California for "a while", we probably legitimately want to use it. If N. California completely goes down, we almost certainly want to keep things alive and send writes to Mars, even if Mars is at a huge network distance, since "slow write" is probably almost always better than "complete failure" (although maybe Mars bandwith is so much more expensive that we don't want to fail over to it, or the size of the link is small enough that it simply can't accommodate the failover traffic).

Ah, link speed vs latency is interesting.

Is "use measured latency" probably always the correct rule in your (hypothetical) cluster setup? Or do you have any cases offhand where it isn't the desired result, and you really want to send traffic to a more distant node on the network?

I don't currently expect anyone to be deploying multi-region clusters in the first iteration of real clustering, so this isn't high on my list of things to fix in this round.

See also T10884 for related work: ranking similar nodes more intelligently.

See also T10883 for related work: making some nodes read-only.

Thanks -- T10778 had instructions which I was more successful with. This should be fixed in HEAD.

Oh, thanks. I can reproduce this variant of things. I thought I remembered seeing this...

Do you have a stack trace in your webserver error log? (Often /var/log/apache2/error.log or similar.) I can't immediately reproduce this myself, but that might help narrow down the cause.

The GIF data is set to repeat the animation only once (see circled control in footer):