I talked of this a while back and remembered I did a first draft of it for new contributors and a reminder to veteran contributors.
I wanted to make something as generalized as I could. Let me know if some things should be in other places or if there should be more nodes. I love making these and it helps me learn more at a higher level.
EDIT: I'm missing Shoryuken...
1. Don't know what you mean with open git.
2. You update your submodules after the merge, not before. And only when it is needed.
3. You usually don't do it in a single commit. The sequence is write some code -> build -> (optionally) test -> commit -> write some code -> build -> (optionally) test -> commit -> ... -> push
4. If you add new files a commit is not enough, you also need to do a git add.
5. We don't require people to make forum posts when they have finished their work. If there is already a thread on the forum, then it can be used. But a large number of development branches go without a single forum post.
I see pushes on github and can act upon them, if it is obvious that they are complete. Alternatively a github pull request is also welcome.
6. Most of time there will be multiple pushes, before it is time for a pull request. We encourage people to push often, even if their work is not finished yet.
7. Before you commit, you should do a git status to make sure that you don't commit accidentally something you did not intended to commit.
As for your comments: I already wrote about #1 and #4
#2: It should build for sure. Testing after every single commit is not required, though some testing is certainly needed. We are fairly tolerant about WIP commits in the github repositories.
Well, it IS a first draft...
- A contributor has no way of knowing when a submodule update is needed. If they asked, the only answer they would get is "If you're asking, I guess so." So just do it every time. What is wrong with that?
I should have said mysysgit - I'm mistargetting the flowchart at only windows users.
I'll see if I can make it better sometime.
I wanted to make this since, as you pointed out - there's a lot of procedure getting in the way of work. Anything that simplifies it or takes the memorization out of it helps.
- A contributor has no way of knowing when a submodule update is needed.
Sure, he has. Do a git status. If there are some submodule related changes listed after a merge, then one or more submodules were updated.
Doing submodule updates blindly can occasionally get you into trouble too, if you are working on submodules yourself at the same time.
Ah - that makes sense.
okay - so I'll remember that.
EDIT: All part of my master plan to post things that are wrong so Zini has to tell us what's right. Bwahahahahaaa!