<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 6, 2018 at 10:02 PM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu" target="_blank">bzbarsky@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 6/7/18 12:40 AM, Eric Rescorla wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To be a little more concrete about it, In my work I usually end up with a git history that looks like:<br>
<br>
- Checkpoint: function written but doesn't compile<br>
- Checkpoint: compiles<br>
- Checkpoint: most tests pass<br>
- Checkpoint: OK, all tests pass now<br>
- Clang-formatted<br>
</blockquote>
<br></span>
Eric,<br>
<br>
I'd like to ask about another concrete example, mostly because I'm trying to understand how current workflows would work in Phabricator or need to be adapted to it.<br>
<br>
So let's take as a specific example <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1466673" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/s<wbr>how_bug.cgi?id=1466673</a> which consists of 5 changesets:<br>
<br>
1) Sanity-checking changeset that should not involve behavior changes and is there to aid bisection if there end up being regressions.<br>
<br>
2) Mass-changes of a particular kind across a set of interfaces, which should not have behavior changes.<br>
<br>
3) Changes to a module that need review from person A.  May have substantive changes.<br>
<br>
4) Changes to a different module that need review from person B (and are independent of item 3).  May have substantive changes.<br>
<br>
5) Some cleanup that is guaranteed to not include substantive changes changes.<br>
<br>
All five changesets are completely self-contained; the tree compiles and passes tests with just #1 applied, with #1 and #2 applied, etc.<br></blockquote><div><br></div><div>This seems like a good example.</div><div><br></div><div>You would make each of these its own Revision and assemble them into<br>a stack of five Revisions. Here's an example of what this looks like:<br><br>  <a href="https://phabricator.services.mozilla.com/D25">https://phabricator.services.mozilla.com/D25</a><br><br>A more complicated stack, with multiple CLs on the same base CL.<br><br>  <a href="https://phabricator.services.mozilla.com/D21">https://phabricator.services.mozilla.com/D21</a><br><br><br>The general principle here is that the conceptual unit of review is a<br>Revision. Any given Revision may have multiple versions (Diffs) as it<br>evolves. Any given Diff consists of more commits in the underlying<br>VCS.<br><br>I think the thing people are noticing here is that the tooling for<br>supporting this workflow is a bit manual: there's no one-liner [0] that<br>takes the current state of the repo and pushes that into a series of<br>Revisions arranged into a stack, and similarly there's no one-liner<br>that allows you to update the Revisions that have changed. I understand<br>from my colleagues at Facebook that they have a tool called Jellyfish<br>that does this, so maybe that's something we could replicate or get<br>open sourced.<br><br>BZ, I'd actually like to ask you a question. When you are working<br>on a series of changesets and someone askes you for a revision of<br>one of those changesets, do you expect to add a new commit on top<br>of the commit in the changeset, or rewrite it the existing commit?<br><br>-Ekr<br><br><br>[0] It's of course possible to script this, but obviously a tool would<br>be better.<br><br><br><br></div></div></div></div>