Forward port from v1.x

[Fishrock123]

Related PRs: #1520, #1517

I was under the impression we were going to be landing everything in master and then backport any fixes, unless something doesn't apply to master.

/cc @iojs/tc, esp @trevnorris & @indutny

[Fishrock123]

If I could get some quick review here that'd be great. It'd be good to get these into 2.0.0 so that we don't have divergence.

[bnoordhuis]

Rubber-stamp LGTM. Maybe run the CI just in case.

[Fishrock123]

Good idea.

CI: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/638/

[Fishrock123]

It would be nice to have some sort of metadata to point to PRs for porting patches. Hmm.

[chrisdickinson]

@Fishrock123 So, in this case I believe the appropriate set of operations would be:

git checkout master
git merge v1.x
git checkout v1.x
git cherry-pick <missing-commits>

[Fishrock123]

@chrisdickinson Some things just got back-ported into v1.x though, won't that cause conflicts now? :/ Or do I just merge with the "ours" rule?

[chrisdickinson]

Ideally this would have gone in first so that the backport commits wouldn't get duplicated.

[chrisdickinson]

I'm going to take a look and see if git chokes on this – I suspect it won't, but it's surprised me before :)

[Fishrock123]

@chrisdickinson any update? Either way the commits should really make it into 2.0.0

[chrisdickinson]

git merge seems to work but produces something of an ugly history with duplicated commits. I'm leaning towards cherry-picking these commits into master at present.

[Fishrock123]

@chrisdickinson would it work if we did a merge from a branch or something from a point where only these two commits existed in v1.x? Or is a cherry-pick still cleaner?

If cherry-pick is cleaner, is this meta-data reasonable?

[chrisdickinson]

The metadata looks reasonable. Try a merge from $(git merge-base master v1.x)+onlythose2changes, but if it doesn't work out, or otherwise produces a complicated history – see git log --pretty=oneline --graph after merging – you should cherry-pick.

[Fishrock123]

@chrisdickinson the result of that is this: https://github.com/Fishrock123/io.js/commits/master-with-v1.x-merge

I'd personally prefer to cherry-pick, but that may not be the best option.

[Fishrock123]

The commit history from git log --pretty=oneline --graph looks like this:

*   daa05ca9448b5ef09740883f8833c21cfa228746 Merge branch 'v1.x'
|\  
| * b3a7da10919445c40f1f36868e529bd2f6ea7269 deps: update http_parser to 2.5.0
| * 5404cbc74533e2d52861221201b166e7c9c015ec buffer: fix copy() segfault with zero arguments
| * 2f6986ee4693b2001f34c98957f337f0cff6204d Working on v1.8.2
* | b4ad5d7050581fe615dab0ec8ef23c83bd965acb doc: improve http.request and https.request opts
* | 550c2638c0885f9cbb1022f8f5234015e21836fe tls: use `SSL_set_cert_cb` for async SNI/OCSP
(... commits ...)
* | 26327757f8b342eb91df71f1fdf34a855e29aa71 doc: update AUTHORS list
* |   59a5c98f2c987080634ed078c9868e23e8c55820 Merge v1.8.1.
|\ \  

[chrisdickinson]

Looking over it, the merge commit should work. Thanks for catching these commits!

[Fishrock123]

replaced by #1582