Star-Demon wrote: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...
Zini wrote: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.
Star-Demon wrote: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.
Zini wrote:- 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.
Star-Demon wrote: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!