<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 2, 2020 at 4:05 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Anyhow, I think as you've pointed out it's just as easy to make a series of commits to a feature branch as it is <br></div><div>to master.</div></div></div></blockquote><div><br></div><div>Exactly. It's even easier, because you can just rebase and rewrite history via `git push -f` at any time, which isn't recommended (or even forbidden) on master.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>On another note-- 0.46.3 with Ico's changes is *slow* on my slow laptop (about like an RPI 4). Like, unusably slow for patches that have a lot of objects on the toplevel.</div></div></div></blockquote><div><br></div><div>I noticed those slowdowns as well. :( That's why I had to go back to rev. 4b7b73cd and nw.js 0.24.4 for now.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>We can't ship a release that takes an order of magnitude longer to load patches. We'll need to spend some serious <br></div><div>time in devTools profiling this, and getting load time back down to reasonable levels before releasing.</div></div></div></blockquote><div><br></div><div>I fully agree with that. Ico's patchset looks very interesting and promising, but it's obvious that it needs more work. So let's move it back into a separate feature branch for now, where work can continue on it without blocking everything and everyone else.</div><div><br> </div><div>Jonathan, I assume that you want to keep linear history on master at all costs, and thus prefer *not* to rebase the master branch? Then we'd have to put everything to be rolled back in one big reversal commit, cherry-pick the commits belonging to Ico's changeset to a new branch and create a merge request for that new branch. Ico can then check out that branch and continue work on it and push to the MR (where others like me can continue to test it), while the master branch will be back in a known good state.<br></div><div><div><br></div><div>That's my basic plan, but let me figure out a process for that on a test branch first, so that we don't wreak havoc on the master branch again. ;-) I have to teach courses today, but I can hopefully set aside some time to have a look at this later today.<br></div></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Best,<br></div><div class="gmail_quote">Albert<br clear="all"></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div></div>