Fri, Jan 24
- Only omit "--" in "git ls-remote", since it seems like it's okay for even very old "git config".
Thu, Jan 23
D20947 does not implement "Author's packages" as a "Commit Content" field, nor as a "Commit Content (Hook)" field. The reason for this is that getting the modern authorPHID in both cases is somewhat complicated.
Tue, Jan 21
The logic here appears to be that gc.auto is set to some value (by default: 6,700). If the number of loose objects exceeds this threshold (technically, if the number of loose objects in objects/17/ is more than 1/256th of this value), it triggers a repack (in a comment, git repack -d -l).
See PHI1613, where an install hit this warning (and resolved it by running git prune):
The issue in PHI1605 resolved itself without apparent intervention, presumably as a result of changes on the CircleCI side. I can't find any release notes to shed any light on things, but this is no longer time-sensitive.
Fri, Jan 17
Thu, Jan 16
See T13478 for followup.
I'm also still able to reproduce this specific variant of things, so it looks like I was too optimistic about T13462 covering this in at least some cases.
Wed, Jan 15
A similar issue occurs when the "Visible To" control wraps with spaces enabled. To reproduce this...
This should be fixed by D20943. Note that "Mute" in this context mutes notifications about edits to the object (e.g. "Alice renamed rule Hxxx from X to Y."), not notifications sent by the rule itself.
This went through cleanly.
These changes seem to have stuck.
Tue, Jan 14
I thought this was some kind of complicated mess with the regex on line 420, but it's actually an issue with this:
- Also move the Porter stemmer.
- Ran some search queries.
(Since a full implementation here will imply that removing a custom field from configuration may "unmention" an arbitrarily large number of relationships, and we can't easily do that inline or at display time, the ultimately implementation would likely include a more robust version of this script.)
In PHI1602, I proposed a script to "reset" mentions on an object. The use case this serves is:
If systems with no binary named python are reasonable to expect, and it sounds like they are, this is fine as-is. I've added you to Blessed Committers so you should be able to land this change yourself (check the project description for some guidance), or let me know if you run into issues. After this lands, I'll land a followup in arc anoid to test for a python3 and emit a friendlier error if it isn't present.
In jira 8.6.1 settings are now in:
- Administration → Applications → Application links
It's possible (and common) to write code that is both valid Python 2 and 3, like in this case.
Mon, Jan 13
This is almost certainly fine, but I don't actually have this bleeding-edge far-future version of Python installed on my stock Macbook (macOS Mojave):
If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.