Can you walk me through why you consider this to be a bug report rather than a feature request?

I actually wasn't sure which to pick myself, since it's not as specific as most bug reports, but it seemed more like undesirable behavior of an existing feature, as opposed to a new feature. Would it be more appropriate to consider this as a feature request instead?

I'm not sure, since I'm not really sure what problem we're solving. It sounds like there are potentially three motivations:

• Resource cost, e.g. CPU and I/O. If you want to motivate this from a resource cost perspective, please measure/quantify the resource costs. I don't see any actual evidence that this is legitimately slow or resource intensive.
• Logging/monitoring. We can go down this path, but it will likely end in "it's easier to ask you to change Phabricator than to change our logging to ignore/de-emphasize no-op pushes since we do monitoring by pointing a spectrometer at the network card" or something like that, i.e. you want us to fix a problem of your own creation which is unique to your install by making Phabricator more complicated for everyone forever.
• Pure aesthetics. We generally favor the aesthetics of the codebase over the aesthetics of Phabricator's interaction with the environment, and are very unlikely to make Phabricator more complex internally to perform fewer pushes if this has no actual cost in real terms and just makes some stuff prettier while imposing a direct complexity cost.

A resource cost motivation might rise to the level of "bug" if this legitimately prevents scaling Phabricator. Scale and security issues have significant leeway to bend the rules.

If you can't quantify a specific resource cost, I think this is generally likely to end in a "wait for T12681, then pay us a lot of money" sort of answer.

To your question specifically: we can change this, but any change will make Phabricator more complicated to maintain and support (the mirroring behavior will become less predictable/consistent for all users if we ever skip pushes). In the general case, we can not determine that a mirror is a no-op by looking at only our own state because a third party may have pushed to the remote since our last push. Any behavioral change here will affect existing installs which may rely on the current behavior to enforce a rule like "keep the GitHub mirror clean/synchronized by continually overwriting it even if someone pushes to it by accident".

We can git ls-remote before pushing to make the no-op determination accurately but the cost may not be much different, and there may be no difference in logging impact.

We can guess if we're going to no-op blindly, but this is a meaningful behavioral change which may negatively impact existing installs. If it's an option/setting, see T8227.

Thanks for the detailed response! We hadn't considered that people might tamper with mirror remotes, so you make a very good point there that our proposed change might cause a regression. And you're quite right that logging is our problem.

Our main concern was on the performance angle, but it's not a huge impact at the moment. We agree it's probably for the best to back off on this one for now -
especially since the bigger win (from our perspective) of cutting down the number of git requests...doesn't actually work.

We still speculate that creating sending N empty packfiles might be much more expensive than running git ls-remote, for both the Phabricator host and the remote host. But it's more of a general "who-knows-what-horrors-lurk-in-the-depths-of-git" (e.g., maybe something is secretly quadratic) - not an evidence-based hypothesis at the moment.