<div dir="ltr">Alright, I'll figure something out.  Ordinarily, I would commit when ready; but for these upstreaming patches there is an approval process that acts like a barrier/sync point. :)</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 3:46 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class=""><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 9:36 PM, Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry, I'll try to limit the commit frequency in the future.  For reference, what would you recommend for spacing out larger collections of patches?  15 minutes per 3?  30 minutes per 5?</blockquote>

</div><br></div>I would commit when ready rather than batching at all.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If it isn't possible for you to commit them incrementally, then I would probably watch the bots cycle between commits or something? I have no idea how to do that reasonably. The entire workflow is really optimized for committing patches as they become ready to commit.</div>

</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>