Change Details

(IMPORTANT) This writeup has some bad assumptions, don't trust it! It's all lies! See PHI1195. See PHI1148. See T11314. Maybe see PHI1067. Some time ago, we updated Diffusion to import all refs in Git repositories. This includes tags and arbitrary non-branch/tag refs, most commonly `refs/pull/*` created by GitHub pull requests and `refs/changes/*` created by Gerrit. When a repository is used as its own staging area, this also includes `refs/tags/phabricator/diff/*`. The "Track Only" and "Autoclose Only" rule specifications were not been updated, and can only apply to branches: refs and tags are always tracked and always autoclose. This primarily creates problems when these various "staging" refs trigger revision closure, and there's no real workaround for this because "Autoclose Only" can't exclude them. A minimal approach might be this rule: - Only branches can be "Autoclose". This probably fixes all the //actual// issues with no configuration changes. The only thing it might break is intentional use of release tags with no corresponding branches, but I believe this is rare or nonexistent. A slightly less-minimal approach would be: - Change the "Autoclose Only" rule list to allow specification of refs in the general case. The current ruleset `master` becomes `branch(master)` or similar, and so on. This isn't terribly bad, but somewhat complex on our side and requires a somewhat-complex migration, and then installs with hundreds of repositories maybe need to go script an API call to update things or something, and we probably want to change the default behavior to "only branches can autoclose" anyway so this is just as breaking as the first change. I'd generally like to move toward a world where "Track Only" is removed. The only "legitimate" use case I know of for "Track Only" (in a world where "Autoclose Only" works properly) is limiting what is fetched from an observed remote with tens of thousands of branches, primarily for performance reasons. This would be better implemented as "Fetch Only" with an explicit ref listing, versus "Track Only" with a complex pattern list. However, removing "Track Only" will require some configuration changes for most installs. Entangled here to some degree are T8093 (virtualizing Git repository refs), `arc save`, and the many open requests to make Staging refs actually work properly (see T13278). Hypothetically, it would be nice to do most of these changes in a single release so we can say "a bunch of ref stuff has changed, here's the complete new behavior so you can update your stuff exactly once" rather than stringing it out over multiple releases. --- Possibly see also T8936.

(IMPORTANT) This writeup has some bad assumptions, don't trust it! It's all lies! See PHI1195. See PHI1148. See T11314. Maybe see PHI1067. See PHI395. Some time ago, we updated Diffusion to import all refs in Git repositories. This includes tags and arbitrary non-branch/tag refs, most commonly `refs/pull/*` created by GitHub pull requests and `refs/changes/*` created by Gerrit. When a repository is used as its own staging area, this also includes `refs/tags/phabricator/diff/*`. The "Track Only" and "Autoclose Only" rule specifications were not been updated, and can only apply to branches: refs and tags are always tracked and always autoclose. This primarily creates problems when these various "staging" refs trigger revision closure, and there's no real workaround for this because "Autoclose Only" can't exclude them. A minimal approach might be this rule: - Only branches can be "Autoclose". This probably fixes all the //actual// issues with no configuration changes. The only thing it might break is intentional use of release tags with no corresponding branches, but I believe this is rare or nonexistent. A slightly less-minimal approach would be: - Change the "Autoclose Only" rule list to allow specification of refs in the general case. The current ruleset `master` becomes `branch(master)` or similar, and so on. This isn't terribly bad, but somewhat complex on our side and requires a somewhat-complex migration, and then installs with hundreds of repositories maybe need to go script an API call to update things or something, and we probably want to change the default behavior to "only branches can autoclose" anyway so this is just as breaking as the first change. I'd generally like to move toward a world where "Track Only" is removed. The only "legitimate" use case I know of for "Track Only" (in a world where "Autoclose Only" works properly) is limiting what is fetched from an observed remote with tens of thousands of branches, primarily for performance reasons. This would be better implemented as "Fetch Only" with an explicit ref listing, versus "Track Only" with a complex pattern list. However, removing "Track Only" will require some configuration changes for most installs. Entangled here to some degree are T8093 (virtualizing Git repository refs), `arc save`, and the many open requests to make Staging refs actually work properly (see T13278). Hypothetically, it would be nice to do most of these changes in a single release so we can say "a bunch of ref stuff has changed, here's the complete new behavior so you can update your stuff exactly once" rather than stringing it out over multiple releases. --- Possibly see also T8936.

(IMPORTANT) This writeup has some bad assumptions, don't trust it! It's all lies! See PHI1195. See PHI1148. See T11314. Maybe see PHI1067. See PHI395. Some time ago, we updated Diffusion to import all refs in Git repositories. This includes tags and arbitrary non-branch/tag refs, most commonly `refs/pull/*` created by GitHub pull requests and `refs/changes/*` created by Gerrit. When a repository is used as its own staging area, this also includes `refs/tags/phabricator/diff/*`. The "Track Only" and "Autoclose Only" rule specifications were not been updated, and can only apply to branches: refs and tags are always tracked and always autoclose. This primarily creates problems when these various "staging" refs trigger revision closure, and there's no real workaround for this because "Autoclose Only" can't exclude them. A minimal approach might be this rule: - Only branches can be "Autoclose". This probably fixes all the //actual// issues with no configuration changes. The only thing it might break is intentional use of release tags with no corresponding branches, but I believe this is rare or nonexistent. A slightly less-minimal approach would be: - Change the "Autoclose Only" rule list to allow specification of refs in the general case. The current ruleset `master` becomes `branch(master)` or similar, and so on. This isn't terribly bad, but somewhat complex on our side and requires a somewhat-complex migration, and then installs with hundreds of repositories maybe need to go script an API call to update things or something, and we probably want to change the default behavior to "only branches can autoclose" anyway so this is just as breaking as the first change. I'd generally like to move toward a world where "Track Only" is removed. The only "legitimate" use case I know of for "Track Only" (in a world where "Autoclose Only" works properly) is limiting what is fetched from an observed remote with tens of thousands of branches, primarily for performance reasons. This would be better implemented as "Fetch Only" with an explicit ref listing, versus "Track Only" with a complex pattern list. However, removing "Track Only" will require some configuration changes for most installs. Entangled here to some degree are T8093 (virtualizing Git repository refs), `arc save`, and the many open requests to make Staging refs actually work properly (see T13278). Hypothetically, it would be nice to do most of these changes in a single release so we can say "a bunch of ref stuff has changed, here's the complete new behavior so you can update your stuff exactly once" rather than stringing it out over multiple releases. --- Possibly see also T8936.