Page MenuHomePhabricator

Render "arc markers" workflows as a tree, not a list
ClosedPublic

Authored by epriestley on Jun 17 2020, 2:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 22 2024, 1:45 PM
Unknown Object (File)
Jan 11 2024, 11:57 AM
Unknown Object (File)
Jan 11 2024, 12:37 AM
Unknown Object (File)
Jan 9 2024, 8:06 AM
Unknown Object (File)
Jan 5 2024, 10:33 PM
Unknown Object (File)
Dec 27 2023, 1:26 PM
Unknown Object (File)
Dec 27 2023, 1:26 PM
Unknown Object (File)
Dec 27 2023, 1:26 PM
Subscribers
None

Details

Summary

Ref T13546. Currently, each "land" workflow executes custom graph queries to find commits: move toward abstracting this logic.

The "land" workflow also has a potentially dangerous behavior: if you have "master > A > B > C" and "arc land C", it will land A, B, and C. However, an updated version of A or B may exist elsewhere in the working copy. If it does, "arc land" will incorrectly land an out-of-date set of changes.

To find newer versions of "A" and "B", we need to search backwards from all local markers to the nearest outgoing marker, then compare the sets of changes we find to the sets of changes selected by "arc land".

This is also roughly the workflow that "arc branches", etc., need to show local markers as a tree, and starting in "arc branches" allows the process to be visualized.

As implemented here ,this rendering is still somewhat rough, and the selection of "outgoing markers" isn't good. In Mercurial, we may plausibly be able to use phase markers, but in Git we likely can't guess the right behavior automatically and probably need additional configuration.

Test Plan

Ran "arc branches" and "arc bookmarks" in Git and Mercurial.

Diff Detail

Repository
rARC Arcanist
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision was not accepted when it landed; it landed in state Needs Review.Jun 30 2020, 10:50 PM
This revision was automatically updated to reflect the committed changes.