<div dir="auto">Perfect, thanks!<br><br><div data-smartmail="gmail_signature">Best,<br><br>Ico<br><br>-- <br>Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation<br>Institute for Creativity, Arts, and Technology<br><br>Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu">ico@vt.edu</a><br><br><a href="http://www.icat.vt.edu">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net">ico.bukvic.net</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 8, 2020, 16:38 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jun 8, 2020 at 1:48 PM Albert Graef <<a href="mailto:aggraef@gmail.com" target="_blank" rel="noreferrer">aggraef@gmail.com</a>> wrote:<br>
><br>
> Yeah, git can be a big pita, we've all been through that hell before. :)<br>
><br>
> The simple recipe to stay sane when using git along with a merge and pull request system like on Github, Gitlab et al (which *is* very convenient when used properly), is this:<br>
><br>
> 1. Create a separate branch for *each and every* merge request. *Never* use the master branch for that, as you'll need it to stay in sync with upstream for the final rebase and squash.<br>
><br>
> 2. Just keep committing and pushing to that branch until Jonathan is happy. :)<br>
><br>
> 3. When Jonathan is happy and asks you to tidy up your branch, rebase it on the current master (which usually *will* have progressed since you created your branch) and maybe squash your commits (`git rebase -i') to tidy up the history of your changeset. Force-push the branch with `git push -f`. That way the history stays as clean and as linear as possible, which is always a good thing (TM).<br>
><br>
> 4. Jonathan merges your request and happiness ensues. ;-)<br>
><br>
> At least that's the workflow I've learned and have been happy with. I don't think that this is written down somewhere, but it's tried and proven, and it's just how everybody does it.<br>
><br>
> HTH,<br>
> Albert<br>
<br>
Ico - I just manually "branched" and merged your gui improvements commits:<br>
<br>
<a href="https://git.purrdata.net/jwilkes/purr-data/-/commit/bb80b5e254c1246db9130dd80535623cffb381ec" rel="noreferrer noreferrer" target="_blank">https://git.purrdata.net/jwilkes/purr-data/-/commit/bb80b5e254c1246db9130dd80535623cffb381ec</a><br>
<br>
I used a "*_squashed" branch because I noticed that you had some more<br>
improvements in defaults.css and<br>
I wanted to amend the commit message to reflect those.<br>
<br>
I also edited your g_editor.c changes. The new js function parameter<br>
wasn't needed-- we can just use the<br>
unique id "#newcord" which is reserved for the new, dangling cord being drawn.<br>
<br>
-Jonathan<br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>