Test windows newlines

[schodge]

Fixes the universal newline issue on Issue #57.

(Pdb) p fixes == afixes
True

Still getting a fatal though, apparently unrelated:

c:\github\pep8radius\tests (test_windows_newlines)
λ nosetests --pdb -s test_pep8radius.py
...SSS.fatal: Not a valid object name random_junk_sha

--pdb and --pdb-failures is not dropping me in to debug the fatal.

Sorry for the mess of May stuff in this pull request, I'm not sure how to remove them. If you know how I should clean up my repository to get rid of the detritus it'd be appreciated.

[coveralls]

Coverage remained the same when pulling a3fe923c3fe56a5da4dbfe5aedb8117ebcfe4965 on schodge:test_windows_newlines into bcfec0be0efec563e897289bde2f7fbc76ec367d on hayd:master.

[hayd]

You haven't included any commits here (only merge commits) :s

I suggest using the rebase model for commits to make reasoning about them easier! That is, keep master a copy of upstream/master, only every update it by rebasing (which should just "fast forward", equivalently by git merge --ff-only). At the moment it's contaminated with merge commits.

This keep the network nice and simple/clean https://github.com/hayd/pep8radius/network

I wrote a blog post about this a while ago, I need some more pictures to be fair (someone was asking about consulting about this so may have to create something more professional soon) http://hayd.github.io/2013/git-notes/

[schodge]

I'm tempted to comment that Git and JavaScript have much in common regarding popularity relative to merit... :P

http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

"Git doesn’t so much have a leaky abstraction as no abstraction. There is essentially no distinction between implementation detail and user interface. It’s understandable that an advanced user might need to know a little about how features are implemented, to grasp subtleties about various commands. But even beginners are quickly confronted with hideous internal details. In theory, there is the “plumbing” and “the porcelain” – but you’d better be a plumber to know how to work the porcelain."

[hayd]

I find I use five commands: fetch, rebase, checkout, commit and push (then make pull-request/merge only via github). If you understand each of these in terms of the network graph I think it starts to make sense. If I have to do something more complicated (always because I screwed up one of these)... I google it.

BTW Was this a .decode('utf-8') in pep8radius_main ?

---

First I think you're going to want to nuke your master branch (assuming there's no commits here):

git checkout master
git reset --hard upstream/master
git push origin master --force  # now check network graph on github

http://stackoverflow.com/a/6229837/1240268

Then cherry pick or just do the commit again:

git checkout test_windows_new_lines2 -b  # start new branch off master
git cherry-pick the_commit_sha_from_above_found_via_git_log

IMO master should just be an earlier copy of upstream/master, that way you don't get into these sticky situations. Keep individual branches up to date via rebasing (rather than merging)

git rebase upstream/master

[schodge]

BTW Was this a .decode('utf-8') in pep8radius_main ? <<

Note sure what you mean. The decode is causing a failure in Python 3 now in the new PR, though.

I repeatedly nuked my master and other branches, and still got left with a couple of commits I finally did a rebase -i on to kill. I still don't get why sometimes I pass upstream/master and other times it's upstream master. Your guide was very helpful.

[hayd]

I think the confusing part is that there are two upstreams:

1. which is the actual remote (on githib, and is up to date always)
2. another which is a local backup of upstream, when you last did a git fetch

When you do git push origin master you're pushing onto the actual remote. When you do a fetch you sync your local copy to the remote. When you checkout or rebase onto upstream/master it's with respect to your local copy of that remote.

Hmmm I actually think this is also something fundamental in understanding git.

Thanks for the feedback, if there's anything else you think a git guide is missing would love to hear it (then I can maybe cover it in a presentation - which I'll also publish online).

RE the .decode('utf-8') I'd thought it looked from your error that the result of pep8radius_main(['--list-fixes']) was not unicode, and was the thing causing the upset... I had not seen your "(see the problem?)" message. Wow, that's kinda amazing... No idea why the other wouldn't have \r\ns.

[schodge]

I think this is the same problem where diff'ing was giving *nix style paths - its output is Unix-style, apparently including on using \n instead of a windows-style \r\n - whereas I bet check_output returns a platform-appropriate string. (I've been working with serial port applications the last six months, so I've grown rather sensitive to terminations and the troubles they can cause...)

[hayd]

Wheras before it was a bytestring in python 2 and a bytestring in python 3 (both have an decode), it's a str in python 2 and a str (unicode) in python 3, the latter doesn't have a decode.

Ooooh, I bet from __future__ import unicode_literals will work?