BUG: closes bug in stack when index is not unique
closes https://github.com/pydata/pandas/issues/10417

can you rebase
 @jreback rebased
 thanks!
 @jreback _my_ version of travis build of pandas fails (https://travis-ci.org/behzadnouri/pandas/builds), do u know why is that and how to fix it? 

it seems that pandas have recently made some changes to travis setup, and for whatever reason those changes are not picked up on my side. is there anything that i have to do manually?
 hmm, odd, we did remove `pandas/version.py`, but that's should cause an issue on travis. you sure you are based on remote master?
 merged version passed ok: https://travis-ci.org/pydata/pandas/builds/74690863
 **my** hook of travis fails, not pydata;
i.e. this one: https://travis-ci.org/behzadnouri/pandas/builds
not this: https://travis-ci.org/pydata/pandas/builds

i have rebased couple of times, and `origin/master` is identical to `upstream/master` but still it fails.
 no I know. that's a bit odd. I wonder if travis is doing something like migrating infrastructure (and yours is migrating).
 @behzadnouri, would the `factorize()` in `pandas.core.algorithms` not work here?

I'm trying to rebase #9023 (which I think addressed the issue of this PR, among other things), and am wondering what was the reason for defining a local `factorize()`.
 a categorical is created with factorize
this just takes advantage of a unique index
 So it's purely a speed optimization? If so, can it be incorporated in to `pandas.core.algorithms.factorize()`? It seems rather confusing to define a new function of the same name and similar behavior (at least I was confused).
 no this is a special case

you normally DO want to factorize even unique indices except in some certain cases
 FWIW, I deleted the specialized local `factorize()` as part of rebasing #9023 (for no particular reason other than that I didn't understand why it was necessary), and all tests pass: https://travis-ci.org/pydata/pandas/builds/77865221.
