A practical question, not specific to a potential SCVim submodule: how do changes to a submodule propagate to the main SC repo? Do they automatically update in SC or is a separate commit in the SC repo required?

It doesn't update automatically to the supercollider repo when making changes in the scvim repo.
IMO that is an advantage, isolating and focussing dev effort for scvim.
When everything is working fine you make a commit in the supercollider repo, updating which commit the scvim submodule references.

Yes, I can see the nice side of it. And if you wanted to make changes to the submodule from within the SC repo, would that also be possible?

Please don't get me wrong. I am not opposed to this. I have been thinking about this in the context of other submodules, so I more or less abuse your suggestion to talk about this on more general terms. I think it is pretty difficult to change a submodule on the SC side. Once the SM is established you have to submit a PR to the submodule repo, and then another one to the SC repo, if I am not mistaken. So on one side a submodule encapsulates an area of SC development and allows to assign separate access rights to it. On the other hand it complicates the workflow and changes control rights. As long as the relations between parent and child repo are constructive, this can be nice, but if that changes, or if the submodule repo is not maintained any more, things have to be changed again. It's not a big change, but worth a thought...

AFAIK you can't make change from the SuperCollider repo.
I don't really know why you would want to do that though? In what case would that would be necessary?

What you can do is to fork the scvim repo and experiment with it. Then new features could be merged to the supercollider/scvim repo later.

+Eirik Blekesaune

Den 24. mar. 2016 kl. 12.06 skrev Rainer Schütz notifications@github.com:

Yes, I can see the nice side of it. And if you wanted to make changes to the submodule from within SC the SC repo, would that also be possible?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

Oh, a submodule in the SC repo... Yes, then half of what I was considering isn't relevant...

Hi Rainer,
I do get the feeling that the thing you want to discuss is a broader topic, not fitting the scope of this particular issue. Although it is an interstimg topic indeed, I'm merely a git novice so this issue would not be the best forum for discussing git in general.
Please correct me if I'm wrong here, but if you agree I propose that we move that discussion to the sc-dev list, or make another issue. I think that would serve both issues best.
This issue is only about moving scvim into a sumodule for making development better.
+Eirik Blekesaune

Den 24. mar. 2016 kl. 14.07 skrev Rainer Schütz notifications@github.com:

Please don't get me wrong. I am not opposed to this. I have been thinking about this in the context of other submodules, so I more or less abuse your suggestion to talk about this on more general terms. I think it is pretty difficult to change a submodule on the SC side. Once the SM is established you have to submit a PR to the submodule repo, and then another one to the SC repo, if I am not mistaken. So on one side a submodule encapsulates an area of SC development and allows to assign separate access rights to it. On the other hand it complicates the workflow and changes control rights. As long as the relations between parent and child repo are constructive, this can be nice, but if that changes, or if the submodule repo is not maintained any more, things have to be changed again. It's not a big change, but worth a thought...

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

Sure. Sorry for interfering.

vim and emacs both have several very good package management systems.
vundle, pathogen
elpa, marmalade

I don't think publishing is difficult

IMO its much better to install from those and not to include it with
supercollider at all.

if you don't want to take ownership of it then it could be moved to the
supercollider org.

On Thu, Mar 24, 2016 at 2:22 PM Rainer Schütz notifications@github.com
wrote:

Sure. Sorry for interfering.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1921 (comment)

https://twitter.com/crucialfelix
https://medium.com/@crucialfelix
http://www.mattermind.com/

And if you wanted to make changes to the submodule from within the SC repo, would that also be possible?

What you can do is to fork the scvim repo and experiment with it. Then new features could be merged to the supercollider/scvim repo later.

The way submodules are described above lead me to believe that you might not be understanding completely how submodules work. A submodule is just a git repo which is checked out inside the working tree of another git repo. The parent git repo only keeps track of what is the address/location of the (submodule) repo and at which commit it should point to. Therefore it doesn't make much sense to ask if you can make changes from "within" the sc repo. All changes to the submodule are made in the corresponding git repo, the sc repo then chooses to which commit it wants to point at. I hope this clarifies somewhat. Also, when dealing with git repos "control rights" are not very relevant, if for some reason we loose control of the scvim submodule, we just fork it and point to the new fork, issue solved. That's the beauty of the distributed approach.

I don't see a big difference between the current state and the submodule approach, but yeah why not.

@bagong is right that you have to make a change in the submodule, then update the main repo to point to the updated submodule; so maybe that's 2 PRs rather than one, but that's kinda the same as committing in an experimental branch and then PR'ing to master.

If it was a submodule, people could file/discuss issues specifically with that, and also they could subscribe just to that repo etc. Not a massive change, but yeah why not

@bagong is right that you have to make a change in the submodule, then update the main repo to point to the updated submodule; so maybe that's 2 PRs rather than one, but that's kinda the same as committing in an experimental branch and then PR'ing to master.

If every commit to the submodule is supposed to appear in the parent repo immediately then I don't think there is much point in having a submodule, it would indeed be more work. If on the other hand the parent repo will only update the commit pointed to every so often, then it makes more sense, imho.

@miguel-negrao , I am likely a bit oversensitive, but asking a question doesn't necessarily point to a lack of understanding, and even if it were so, why should an explanation be headed by pointing to an assumed lack of understanding first? This is not a very encouraging discussion style, if I may say so.

So, as an example, I had a tiny pull request hanging in hidapi for something like three months, and after I it was committed, I had to make another pull request to try and bring it into 3.7. Too late... Not a big deal at all in this case, but - as I feel - an instructive example of the potential implications of splitting out things into different repos.
Sure you can just link to another fork, but it's not particularly friendly behavior, so you might want to choose to avoid it becoming necessary.

And now I'll be quiet for a while... Have been talking a bit much lately...

Please understand, my only goal here is to fascilitate more communication amogst scvim users and developers.
I'm not sure if the solution for this is making it into a submodule or not.
Crucialfelix' suggestion also seems reasonable to me. It is the same method he is using for the Atom.js SuperCollider plugin if I'm not mistaken(?)
However that would raise the question if SuperCollider should package scvim, and any other editors than sc-ide for that matter. Any opinions on this?

Miguel:
Maybe I misunderstand you but I don't see why we would need to have every commit in the submodule to be comittef to the main repo. Wouldn't that kind of defeat the purpose of putting it into a submodule? Then you would indeed have to do 2 PRs for every commit.

+Eirik

Den 24. mar. 2016 kl. 16.16 skrev Miguel Negrão notifications@github.com:

@bagong is right that you have to make a change in the submodule, then update the main repo to point to the updated submodule; so maybe that's 2 PRs rather than one, but that's kinda the same as committing in an experimental branch and then PR'ing to master.

If every commit to the submodule is supposed to appear in the parent repo immediately then I don't think there is much point in having a submodule, it would indeed be more work. If on the other hand the parent repo will only updated the commit pointed to every so often, then it makes more sense, imho.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

@miguel-negrao , I am likely a bit oversensitive, but asking a question doesn't necessarily point to a lack of understanding, and even if it were so, why should an explanation be headed by pointing to an assumed lack of understanding first? This is not a very encouraging discussion style, if I may say so.

@bagong Thank you for pointing that out. That was not my intention, and it is good to know that my post was construed as conflictive. I will try to work on my discussion style, you're right I could have been more constructive. Asking a question doesn't necessary imply lack of understanding, but sometimes the way the question is asked can demonstrate that there is some confusion regarding the matter. I thought I had identified some confusion, and tried to clarify, with good intentions. Off course, I can see that if one thinks there was no confusion to start with, then a clarification can be perceived as condescending. I tried to use language which expressed only the possibility of confusion: "lead me to believe", so perhaps I was believing so wrongly; "that you might not be", but leaving the possibility that you are understanding correctly. Anyway, sorry about that. :-)

Miguel: Maybe I misunderstand you but I don't see why we would need to have every commit in the submodule to be comittef to the main repo. Wouldn't that kind of defeat the purpose of putting it into a submodule? Then you would indeed have to do 2 PRs for every commit.

@blacksound That is exactly what I said, so I agree with you. :-)

#1930 Maybe worth a review?

The main reason to have it as a separate repo is so that it can be loaded easily by things like Vundle and NeoBundle:

Plugin 'supercollider/vim-supercollider'

voila, you now have supercollider support in your vim. Other package managers use similar syntax.

Likewise, for Emacs Devotees we publish a separate repo to melpa:

https://melpa.org/

by adding a recipe to:
https://github.com/melpa/melpa

in the form of:

(supercollider-mode :fetcher github :repo "supercollider/emacs-supercollider-mode" :files ("supercollider-mode.el"))

or something like that. Then all the different Emacs package managers can all access it from melpa.

I don't see why these files should continue to be distributed with SuperCollider. Doesn't everybody use a package manager on vim and emacs ?

I'm not fussed about keeping them in though. But it's not needed IMO. It would reduce maintenance, allow people to contribute more easily to those packages and get instant distribution—no need to wait for a new SuperCollider release.

What you can do is to fork the scvim repo and experiment with it. Then new features could be merged to the supercollider/scvim repo later.

^^ this.

Plugin 'blacksound/vim-supercollider'

and you are free to hack away.

It seems this is a fine idea, I don't think anyone objects much to this. Question: is there anyone who would like to supervise the scvim repo after we create it? I guess we can just create it and see what happens, but really there needs to be a nonzero number of people looking after PRs etc!

I use Vim and I am interested in contributing to improve the SCvim module, so count me in =)