Revert "Fixed issue #74, except for color codes"

[ntwitch]

This was already fixed in 93352e1
I forgot to mention it, so dgets fixed it again.

This reverts commit 6120bea.

[deutrino]

This project is gaining frequent-enough commits (and associated conflicts) that we should adopt common github and git branching conventions. I'll need a bit of a refresher myself as I've only used bare git branching at previous jobs since we didn't pay Github - Github's pull request mechanism is great, but I've mostly used external tools which provide the same functionality (namely, code review and a chance for >1 set of eyeballs before changes are merged).

I'll help @dgets write up a short doc on this.

With git alone, the typical workflow is to make a branch for every bug or feature worked on, code review it, then merge back to master and fix conflicts. If it's a long-running branch, you can ::mumble:: from master so conflicts are less of a problem (or if master or another branch gets a feature you suddenly want), where ::mumble:: is something like 'pull', 'merge' or 'rebase'. Beware the latter, for it is arcane and easily angered when summoned. 'cherry-pick' is also worth reading on; these are all git subcommands.

The upshot - if you're working in your own Github fork, you can be working on 5 bugs and features at once, and switch between them because they're in 5 different branches. With several devs working together, issues will frequently stall and/or other devs may need help, so this is a Good Thing.

[ntwitch]

This is already pretty much my workflow, I've contributed to a Github project before and was instructed on the proper conventions.

Branch, (edit code, commit, test)^n, if conflicting changes have been made upstream: pull, merge, cherry-pick, rebase, or rewrite conflicting code as needed, push the branch to my Github fork repo, and then I generate a pull request for the main project.

I'm still accepting of advice though, if you can see anywhere I need to make improvements to my process :)

We haven't been doing any code reviewing, though. If my changes appear to be working after I test for a bit, I go ahead and merge into master, but this is a relatively small and simple project so I haven't worried about it.

On Wed, Mar 4, 2015 at 9:06 AM, Gordon Morehouse [email protected]
wrote:

This project is gaining frequent-enough commits (and associated conflicts)
that we should adopt common github and git branching conventions. I'll need
a bit of a refresher myself as I've only used bare bit branching at
previous jobs - Github's pull request mechanism is great, but I've mostly
only used external tools which provide the same functionality (namely, code
review and a change for >1 set of eyeballs before changes are merged).

I'll help @dgets https://github.com/dgets write up a short doc on this.

With git alone, the typical workflow is to make a branch for every bug or
feature worked on, code review it, then merge back to master and fix
conflicts. If it's a long-running branch, you can ::mumble:: from master so
conflicts are less of a problem (or if master or another branch gets a
feature you suddenly want), where ::mumble:: is something like 'pull',
'merge' or 'rebase'. Beware the latter, for it is arcane and easily angered
when summoned. 'cherry-pick' is also worth reading on; these are all git
subcommands.

The upshot - if you're working in your own Github fork, you can be working
on 5 bugs and features at once, and switch between them because they're in
5 different branches. With several devs working together, issues will
frequently stall and/or other devs may need help, so this is a Good Thing.

—
Reply to this email directly or view it on GitHub
#78 (comment).

[dgets]

We should work with branches other than master. I just need to like figure out how to do that and stuff. :P