[L2Ork-dev] Bunch of commits and a merge request from my branch

[Jonathan Wilkes]

On Mon, Jun 8, 2020 at 1:48 PM Albert Graef <aggraef at gmail.com> wrote:
>
> Yeah, git can be a big pita, we've all been through that hell before. :)
>
> 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:
>
> 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.
>
> 2. Just keep committing and pushing to that branch until Jonathan is happy. :)
>
> 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).
>
> 4. Jonathan merges your request and happiness ensues. ;-)
>
> 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.
>
> HTH,
> Albert

Ico - I just manually "branched" and merged your gui improvements commits:

https://git.purrdata.net/jwilkes/purr-data/-/commit/bb80b5e254c1246db9130dd80535623cffb381ec

I used a "*_squashed" branch because I noticed that you had some more
improvements in defaults.css and
I wanted to amend the commit message to reflect those.

I also edited your g_editor.c changes. The new js function parameter
wasn't needed-- we can just use the
unique id "#newcord" which is reserved for the new, dangling cord being drawn.

-Jonathan