ENH: implement Block splitting to avoid upcasts where possible (GH #2794)
- provides an implementation of IntBlock splitting that can avoid upcasting (to float) these blocks if a boolean condition does not affect the column, closes GH #2794)
- bugfix in internals.Block.putmask; was upcasting always on an int; and upcasting to float, (now float64)

```
In [6]: df = pd.DataFrame(1,columns=['a','b'],index=range(3))

In [7]: df.ix[1,'b'] = 0

In [8]: df
Out[8]: 
   a  b
0  1  1
1  1  0
2  1  1

In [9]: df.dtypes
Out[9]: 
a    int64
b    int64
Dtype: object

In [10]: df[df>0].dtypes
Out[10]: 
a      int64
b    float64
Dtype: object

In [11]: df[df>0]
Out[11]: 
   a   b
0  1   1
1  1 NaN
2  1   1
```

@y-p I obviously merged this (to catch up with some changes in master); the merge commit is there, but doesn't 'affect' things....is this correct?
 it depends on what master contained at the time you merged. If this gets merged in a month
after many changes, yes it could create problems. just rebase or use reset and "git add -i/-p"
to make new commits.
 so i just rebase and pick out my 3 or so commits (just like normal)....what about the 'merge' changes? just leave them out in the rebase?
 @y-p thanks...i had done a strigiht `git pull` instead of `git pull --rebase` ....fixed
 I sometimes do this, to fix that sort of thing:

```
git checkout -b temp_branch this_branch # work in sandbox
git merge upstream # sync
git reset upstream/master # leave tree as is, reset HEAD to master
git status # show uncommited changes
while remaining_changes:
    git add -p # select chunks to include in commit
    git commit -m "message"
echo voila
```

also, git has a tweak to always rebase:

```
$ git config branch.autosetuprebase always
$ git config branch.*branch-name*.rebase true
```

http://stevenharman.net/git-pull-with-automatic-rebase
 you r git-fu master

me just going to turn on auto rebase
