Change Details

See PHI1225. I haven't actually walked through these repro steps so this is slightly hypothetical, but: - Create a repository R with only branch X as a permanent ref. - Push commit C to branch Y. - Mark branch Y as permanent. Expected behavior: C is published (it is now reachable from permanent ref Y). Actual behavior: C remains unpublished. Workarounds: Probably, push another commit to Y, or push C to another permanent ref. In `PhabricatorRepositoryRefEngine`, we should close every reachable commit on Y if it becomes a permanent ref. We'll currently skip this step because we won't create a new cursor for it. --- Likely adjacent is that the `RefPosition` table should likely store (a) is this ref the repository default ref and (b) is this ref a permanent ref. We probably need to do (b) to fix this (automatically publish commits when a ref becomes permanent). Doing both (a) and (b) will let us query a list of branches with a more human-readable ordering (see D20493). --- Related, see PHI1264. If users interact with an unpublished commit after it has imported, it currently does not send email/notifications/etc. This is incorrect: explicit user interaction with unpublished commits should work normally.

See PHI1225. I haven't actually walked through these repro steps so this is slightly hypothetical, but: - Create a repository R with only branch X as a permanent ref. - Push commit C to branch Y. - Mark branch Y as permanent. Expected behavior: C is published (it is now reachable from permanent ref Y). Actual behavior: C remains unpublished. Workarounds: Probably, push another commit to Y, or push C to another permanent ref. In `PhabricatorRepositoryRefEngine`, we should close every reachable commit on Y if it becomes a permanent ref. We'll currently skip this step because we won't create a new cursor for it. --- Likely adjacent is that the `RefPosition` table should likely store (a) is this ref the repository default ref and (b) is this ref a permanent ref. We probably need to do (b) to fix this (automatically publish commits when a ref becomes permanent). Doing both (a) and (b) will let us query a list of branches with a more human-readable ordering (see D20493).

See PHI1225. I haven't actually walked through these repro steps so this is slightly hypothetical, but: - Create a repository R with only branch X as a permanent ref. - Push commit C to branch Y. - Mark branch Y as permanent. Expected behavior: C is published (it is now reachable from permanent ref Y). Actual behavior: C remains unpublished. Workarounds: Probably, push another commit to Y, or push C to another permanent ref. In `PhabricatorRepositoryRefEngine`, we should close every reachable commit on Y if it becomes a permanent ref. We'll currently skip this step because we won't create a new cursor for it. --- Likely adjacent is that the `RefPosition` table should likely store (a) is this ref the repository default ref and (b) is this ref a permanent ref. We probably need to do (b) to fix this (automatically publish commits when a ref becomes permanent). Doing both (a) and (b) will let us query a list of branches with a more human-readable ordering (see D20493). --- Related, see PHI1264. If users interact with an unpublished commit after it has imported, it currently does not send email/notifications/etc. This is incorrect: explicit user interaction with unpublished commits should work normally.