Change Details

See PHI1804. Previously, see T13284, which has a more detailed discussion of the general case of this behavior. Broadly, the setup here is: - commit C is pushed to non-permanent branch "epriestley-tmp-123"; - later, commit C is pushed to permanent branch "master". After T13284, we correctly reprocess "C" when it becomes reachable. However, the reprocessing effectively skips the "Message" step, which has some side effects beyond parsing the message -- notably, closing related revisions and tasks. This means that revisions related to C are not closed. The cleanest fix is to move these actions to "Publish", since they're really publish actions anyway and other publishing stuff already happens there. The major issue I see with this is that these actions currently depend on a `DiffusionCommitRef` object, which is available in the "Message" step but not in the "Publish" step. These actions also have some side effects that impact commit data and are not "pure" publish actions.

See PHI1804. Previously, see T13284, which has a more detailed discussion of the general case of this behavior. Broadly, the setup here is: - commit C is pushed to non-permanent branch "epriestley-tmp-123"; - later, commit C is pushed to permanent branch "master". After T13284, we correctly reprocess "C" when it becomes reachable. However, the reprocessing effectively skips the "Message" step, which has some side effects beyond parsing the message -- notably, closing related revisions and tasks. This means that revisions related to C are not closed. The cleanest fix is to move these actions to "Publish", since they're really publish actions anyway and other publishing stuff already happens there. The major issue I see with this is that these actions currently depend on a `DiffusionCommitRef` object, which is available in the "Message" step but not in the "Publish" step. These actions also have some side effects that impact commit data and are not "pure" publish actions. --- See PHI1998, which identifies issues with the repository "Tags" interface: - It is significantly different from the "Branches" interface, although both objects are very similar. - It does not interact correctly with author identities. - When a tag ref points at a tag object, but the tag object has no message, the UI shows no message at all. - Instead, it should probably always show the commit message, and then additionally show the tag message if a tag object with a message exists. - When a tag ref points at a tag object, the UI should show the commit hashes for both the tag object and the commit object.

See PHI1804. Previously, see T13284, which has a more detailed discussion of the general case of this behavior. Broadly, the setup here is: - commit C is pushed to non-permanent branch "epriestley-tmp-123"; - later, commit C is pushed to permanent branch "master". After T13284, we correctly reprocess "C" when it becomes reachable. However, the reprocessing effectively skips the "Message" step, which has some side effects beyond parsing the message -- notably, closing related revisions and tasks. This means that revisions related to C are not closed. The cleanest fix is to move these actions to "Publish", since they're really publish actions anyway and other publishing stuff already happens there. The major issue I see with this is that these actions currently depend on a `DiffusionCommitRef` object, which is available in the "Message" step but not in the "Publish" step. These actions also have some side effects that impact commit data and are not "pure" publish actions. --- See PHI1998, which identifies issues with the repository "Tags" interface: - It is significantly different from the "Branches" interface, although both objects are very similar. - It does not interact correctly with author identities. - When a tag ref points at a tag object, but the tag object has no message, the UI shows no message at all. - Instead, it should probably always show the commit message, and then additionally show the tag message if a tag object with a message exists. - When a tag ref points at a tag object, the UI should show the commit hashes for both the tag object and the commit object.