<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 7, 2018 at 9:51 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 6/7/18 3:34 AM, Eric Rescorla wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You would make each of these its own Revision and assemble them into<br>
a stack of five Revisions.<br>
</blockquote>
<br></span>
OK, that makes sense.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the thing people are noticing here is that the tooling for<br>
supporting this workflow is a bit manual<br>
</blockquote>
<br></span>
Yep.<span><br></span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<br></span>
It depends.<br>
<br>
Full disclosure, I use mq for the most part.<br></blockquote><div><br></div><div>I hear we're not supposed to do that :)</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I'm asked for a change to a changeset, I will usually edit it in-place and qrefresh.  I'm using "qinit -c" to have versioned queues, with auto-commit on qrefresh, so I can use that to roll back if needed.<br>
<br>
If the changes are complicated I might end up doing it as a separate commit on top and then qfold once I'm happy with it.  In fact, I might do the separate commit on top of the whole series and then reorder and qfold, depending.<br>
<br>
In all cases, by the time I'm done my local state matches the state I want to be pushing to the public tree, with no fixup changesets, etc, remaining.</blockquote><div><br></div><div>When you say "done" I assume you mean "by the time I ask for review"? If so, I think that's fine, but I don't think we should require it as the only way to roll, especially because with Git it kind of messes with your history in an annoying way (in that it's hard to then get back to the history of each CL).<br></div><div><br></div><div>-Ekr</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_1988159110791343148HOEnZb"><div class="m_1988159110791343148h5"><br>
<br>
-Boris<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div></div>