In my case (using GMail) it appears to thread properly as well however apparently some clients (KMail) rely on these headers more heavily than others.

Okay. For the sake of 100% clarity it would be nice if the timeline story did show why the action was taken as it isn't immediately clear (unless you've read the documentation of course) why it was removed.

Ah, that would certainly explain it. Sorry for the noise - when entering this I did wonder if I had missed something as it didn't make sense that a name collision would be able to cause this.

For those of us who don't mind having to wait through a large reindex after restoring from a backup, is there a way to ask the backup process to skip dumping the index tables? (Based on the above I presume they'll still be included)

Not a problem - thanks for fixing that so quickly.
I can confirm that fixed the issue for us.

This change creates a slight problem for us at KDE as we have some historical commits in our Subversion repository which have URLs in them which are invalid. This exception means that:

• Herald spins forever trying to process these commits, failing every single time (currently up to 855 failures).
• The commit can't be viewed in the browser (See https://phabricator.kde.org/R883:271607)

KDE has some interest in this as our contributors are distributed around the world.

@mrybczyn Is someone who is a member of the KDE Community yes, but I don't know if this task relates to stuff they do in KDE though. Based on their activity page on Phabricator i'm inclined to think this isn't KDE related but I could be wrong.

@epriestley my apologies for this. I had sent out a memo previously asking for everyone to file tasks on our Phabricator so that I could co-ordinate things from there. It seems some folks have missed that, so i've now resent it to a wider audience.

Yes, sticky-accept is True.

I've now added reproduction steps, including details on customised settings for the Differential application.

Sorry, you'll need to provide more detail on what's wrong than repeating your comment. I added the version information to the Task Description.

This report is against Differential.

I would imagine they're using something along those lines yes. I think we'll probably keep a bunch of people happy if pushing Git refs up were supported.

Chances are we're going to get complaints that go either way. Myself, i'd tend to prefer T5000.

We've had some people in KDE kick up some fuss about this.

Some parts of KDE use git notes fairly extensively for certain specific workflows.
How difficult would it be to have Phabricator permit pushing Notes, even if Phabricator itself didn't do much with them (doesn't need to display them)?

How difficult would this be for someone to implement / does upstream have an implementation timeline for this?

Thanks for the quick fix.
I realise now I was always trying to change the access policies....