<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head><body style="font-family: tt;" text="#000000" bgcolor="#FFFFFF"><div
style="font-family: tt;"><span style="font-family: monospace;">i would
create a stack of revisions, as per
<a class="moz-txt-link-freetext" href="https://smacleod.ca/posts/commit-series-with-phabricator/">https://smacleod.ca/posts/commit-series-with-phabricator/</a><br><br>this
won't squash the commits, and is extremely close to the commit series we
know and love in mozreview. there are ergonomics that need to be
worked on (particularly around landing a stack) which are already on the
roadmap[1] as the next thing our team will be focusing on.<br><br><br>-glob<br><br>[1]
<a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/Engineering_Workflow/Road_Map#Lando_for_All">https://wiki.mozilla.org/Engineering_Workflow/Road_Map#Lando_for_All</a><br><br></span><br><span>Boris
Zbarsky wrote on 7/6/18 1:02 pm:</span><br><blockquote type="cite"
cite="mid:5753c546-676e-81fa-fc52-f4f1c700cb12@mit.edu">All five
changesets are completely self-contained; the tree compiles and
passes tests with just #1 applied, with #1 and #2 applied, etc.
<br>
<br>With your experience using Phabricator, how would you split this
sort of
work up into changesets and revisions (in the Phabricator sense) to
maximize ease of review and bisectability?
</blockquote><br><div class="moz-signature">-- <br><span style="color:
rgb(192, 192, 192);">glob — engineering workflow — moz://a</span><br>
<br>
</div></div></body></html>