Added some bug fixes and some new functionality to the existing code,…

[amopremcak]

… like saving monitor and led information to the registry.

[DanielSank]

Delete white space at end of line.

[amopremcak]

I can make these changes. Should I submit a new pull request once they are made?

[DanielSank]

In general you just push more commits to the pull requested branch, but in this case see my notes below.

[DanielSank]

Thanks much for doing this.

Warning: this is a lot of information on how to manage your workflow in git. It's not meant as criticism or to waste your time, but rather to help you guys integrate into how we do things and establish good practices so you can continue to contribute as much as possible in the future. In other words, I'm picking on stuff now so that things are smoother down the road.

It's good practice to keep pull requests as small and issue-specific as possible. This one addresses two things: 1) Fixing bugs in existing code, and 2) adding new features. We want to separate those things. It's easiest for the reviewer and for anyone looking at the repository history if those two things happen separately. It's important to focus on making the reviewer's life as easy at the cost of making the author's life a bit harder because the reviewer is already at a disadvantage in that he/she is usually less familiar with the code in question.

One way to remember to do this is to file an issue before making any change (which you did) and then always make each branch in git dedicated to one single issue. In the future that's probably a good way to go.

See #292 for further discussion.

Here are the steps you can take to fix this all up. It looks like a lot, but it's not hard and you might pick up a really cool piece of git-fu.

1. Make a new branch to do your fix-up work.

   $ git checkout master  # probably you're already there and this does nothing
   $ git checkout -b fix_dc_rack_server
   

2. Roll back the commit history, but keep the actual changes to the files.

   $ git reset --soft HEAD~1
   

   The ~1 means "go back one commit" and the --soft means "move the branch pointer back but don't actually change the files in my file system". If you now do

   $ git status
   

   You'll see that the files you modified in this PR are indeed marked as changed and added. Now you can do

   $ git reset HEAD dc_rack_server.py
   

   to un-stage the changes. You now have unstaged changes. It's as if you just finished editing the code but haven't told git about it yet.

3. Add the changes, but separate the bug fixes from the new features. This is the cool part.

   $ git add --patch
   

   This takes you into a really neat system where you can decide which line changes you want to add to the git staging area. Only add the bug fixes here. Google search "git add --patch" if it's not obvious how to use the interface. This is worth your time, git add --patch is really useful.

4. Commit bugfix changes.

   git commit -m "Fix asynchrony bugs in dc_rack_server.py."
   git push  # To your github repository
   

5. Hop onto github and file a pull request for fix_dc_rack_server.

6. Stick the rest of the changes (i.e. added features) on a new branch.

   $ git checkout -b dc_rack_features.
   $ git add dc_rack_server.py
   $ git commit -m "Add features XYZ to dc_rack_server."
   

7. Catch up to our repo after the pull request. Once fix_dc_rack_server gets into the upstream master (i.e. our repository), pull that down. This may give you a conflict because our master and your master will have different histories. Touch base at that point.

8. Submit the features for review. Rebase dc_rack_features on master, and then submit it for another pull request.

If this proves too complex we can try to think of another solution. I may be missing something simpler. One thing I can think of is for someone on our end to do the git-surgery, but I think it would be nice for someone over there to learn the tricks of the trade.

[jwenner]

Bump version number?

[DanielSank]

@jwenner this PR was sort of re-issued elsewhere. I think we may actually want to close this one.