This assumption proves to be wrong if the NodeProxy resides in different dictionaries but are stored with the same key.

Yes, that is true. It is better to always add the identityHash.

I think this fixes a bug and should be merged into 3.7. Can you make another pull request for that?

I can make pull request to the 3.7 branch yes. Should I just close this current pull request then?

Ah, proved to be a bit more cumbersome than I initially though.

So from what I understand I would need to get the 3.7 branch into my fork, and then make the commit for that branch. Problem is that my fork doesn't have the 3.7 branch from the main repo. How can I add it to the list of branches in my blacksound/supercollider fork?

If I remember correctly:

git checkout supercollider/3.7
git checkout -b topic-nodeproxy-unique-name
git cherry-pick beeb15e86a208256a67ac778953d038dc675b3c8
git push

And then go to your github repo to make the pull request.

See my comment at #1998

3.8 is only 5 weeks away.

I think you should merge this one, not the 3.7 one.

ups, sorry, git-slap-stick, merged the other one. If you like, merge this one too.

The other one has been merged already. This one must not be merged. Closing.

@chris, I don't think you need to be too worried about merging the same thing in both branches, also not about the "cherry-pick" workflow of moving commits between branches that, as I seem to remember you are opposed against (the reason for which I don't recall). Provided the "patches" apply cleanly in both branches, git will recognize that they are the same and just ignore the commits during a subsequent merge of the branches (based on the "patch-id"). I test- merged 3.7 into master and found that Julian's node-proxy-docu related commit in both branches is ignored (but the merge related to the scvim submodule is tricky ;) ).
I am actually wondering why we don't return to the method of cherry-picking suitable commits from master to 3.7. There is no guarantee that bug-fixes for 3.7 are to be applied to master (which could complicate a merge), and the longer you wait with a merge, the more likely it is that we get complications. Also remember that after merging 3.7.1 into master suddenly 5 pull requests had conflicts, and there is no guarantee that the maintainers of the PR fix those conflicts themselves.
I rather think that cherry-picking suitable commits to master straight away into 3.7 is a good workflow. If - as you stated - you want to take the responsibility of maintaining the 3.7 branch yourself, you could do them without the PR detour. Then "merge 3.7 into master" could be avoided altogether.

I rather think that cherry-picking suitable commits to master straight away into 3.7 is a good workflow. If - as you stated - you want to take the responsibility of maintaining the 3.7 branch yourself, you could do them without the PR detour. Then "merge 3.7 into master" could be avoided altogether

👍

It's not the code commits that I'm concerned about, it's the "Merged Pull Request" and the duplicate Pull Request itself. It was also duplicate work for @blacksound and now we have to debate the whole thing again.

I am actually wondering why we don't return to the method of cherry-picking suitable commits from master to 3.7.

3.7 is basically done now. 3.8 comes out in 5 weeks. Let's not change how this release is done. No bikeshedding.

I can see your point about "after merging 3.7.1 into master suddenly 5 pull requests had conflicts", but I think it's good practice to wait until a new work cycle begins to change the workflow.

Changing and debating all the time is exactly what I want to save us from.

Thank you, you have saved us from a lot already. Of course you can't see what doesn't exist!

I'm wondering why this change doesn't appear in master? Is dependant on having the 3.7 branch being merged with master? When can I see this change in the master branch?

it gets merged in when 3.7.2 comes out which is quite soon.

that's why I said to merge this one to master, not the 3.7 one.
the 3.7 branch doesn't need minor fixes like this.

by releasing more often we ensure that master is the active development branch and the releases are where we put our finished work. but we don't want to waste time doing further work on those releases, just to fix serious bugs.