Differential is a code review tool.
Tue, Jan 16
Tangential, but T8768 is a case where we generated an unfaithful synthetic diff (a diff --git that the git binary could not generate since 2006) and took the blame for it.
Fri, Jan 5
The install in PHI271 reported this as fixed after upgrading.
Thu, Jan 4
Wed, Jan 3
Wed, Dec 27
Tue, Dec 26
T13023 provides an example of a synthetic "git-like" diff generated by some tool (dpkg-source?) which appears (?) to pretend to generate Git diffs (diff --git in the text).
I'll merge this into T12664, but realistically it's exceptionally unlikely that we'll add the ability to parse these diffs given one example and no idea how to generate them in the general case, and apparently only one install encounters these diffs, and they aren't generated with a legitimate VCS tool.
Fri, Dec 22
Dec 13 2017
@epriestley Are there any more concrete plans for this "nonblocking" builds? That is something we would like to utilise for one of our projects. Actually quite important as waiting for builds there is slowing us down quite a bit now.
Dec 5 2017
Dec 1 2017
Nov 28 2017
Nov 23 2017
Obviously not a particularly important issue, but this now will populate a link in the favorites menu which leads to an exception:
Nov 22 2017
Phabricator messes up tab spacing in patches. It should be very easy to replace tabs with spaces and require the use of only monospace fonts.
Nov 14 2017
Nov 7 2017
(Another possibility is to add behavior to arc to control this.)
Maybe. Another possibility is to mark builds as "nonblocking" in some sense. There are some other open requests for defining "advisory" or "noncritical" builds where build failure doesn't cause the Buildable to report a failed result overall. If we end up adding this state to builds anyway, it probably makes sense to include a "Does Not Block Review" flag to the "Does Not Fail Buildable" / "Does Not Block Dependent Builds" / "Failure Is Totally Meaningless" / Whatever flags.
The harbormaster builds that we have running on revision creation can sometimes be rather slow; they're builds in our primary CI system, but with less of a priority than jobs in the submit queue. This will result in 10-30 minute delays for every revision in our monorepo. I understand the preference for only adding configuration settings when absolutely necessary, but since this may result in a significant time sink for any installs with expensive builds, is it worth keeping something around like differential.initial-state?