Question -- Proper GitHub Procedure

[rshartog]

@rambo ,

This is a question -- not an issue, but I couldn't figure out how to ask a question on GitHub. Please know that I have been all over the GitHub help, so I'm not bothering you without trying to find the answer for myself. Please close this issue after you respond.

Please look at the process that I used to create the buffer_mgmt pull request and let me know if there's something I should do differently. I created this list from my bash command history. I don't understand all the steps in the "sync to the head of the master version" section.

GITHUB WEB -- create fork for user

LOCAL -- clone the fork on local machine

   git clone https://github.com/<username>/<project name>.git

LOCAL -- cd into the project

   cd <project name>

LOCAL -- associate the local copy with the original (upstream) master

   git remote add upstream https://github.com/<owner>/<project_name>.git

LOCAL -- view the remote associations

   git remote -v

LOCAL -- sync to the head of the master version

--> why all these steps? <--

   git fetch upstream
   git checkout master
   git merge upstream/master
   git pull https://github.com/<owner>/<project_name>.git
   git push origin master

LOCAL -- create a branch for proposed changes

   git status
   git checkout -b <branch_name> master

LOCAL -- make changes to local stuff and verify

    < make changes and test >

LOCAL -- add changed files

   git status
   git add <changed file name>
   git status

LOCAL -- commit changes (pops up editor for comment)

   git commit

LOCAL -- push changes to the remote repository

   git push --set-upstream origin buffer_mgmt

GITHUB WEB -- create pull request

Also, I noticed that the "fix_rsh" branch still exists even though you merged it. Do I need to do something to clean that up or delete it? I think the buffer_mgmt branch still exists as well. Can I safely delete it now that it's been merged?

--Scott (rshartog)

[rshartog]

Whoa. Apparently starting a line with '#' causes a section header.

[rshartog]

Okay. I saw something on the web saying that the "buffer_mgmt" branch has been merged and that I could delete it, so I did that already.

[rambo]

Yeah, GitHub uses markdown formatting, I like it but you have to know it...

As for the other questions, I'll get back to them later, busy now...

[rshartog]

@rambo Thanks. No rush.

Just a heads-up... I am planning to make the TineWireS library fully interrupt driven. I need this for my battery-based project so that I can shut the Tiny85 down (SLEEP_MODE_PWR_DOWN) when it's not involved in receiving data or responding to requestFrom() calls from the master. In the current code version, the requestEvent scenario is interrupt driven, but the receiveEvent scenario requires the TinyWireS_stop_check() call in the main loop, so the Tiny85 has to run continuously.

I've done some experimenting and I think I have a clean, simple way to modify the code to make the receiveEvent scenario interrupt driven. Then the slave program won't have to call TinyWireS_stop_check(). The current code version does not explicitly recognize when the master stops sending data and this is a little tricky because the I2C master does not execute a proper I2C stop condition (at least not on the ESP8266-12E).

I'll submit with a new slave stress test program that puts the Tiny85 in power down mode between I2C accesses.

--Scott