[PATCH 0 of 2] Cherry picking with rebase

[Tomasz Barszczak]

Stefano Tortarolo wrote:
> This is quite tricky indeed... what if I really wanted to say 'grab
> from D to F including E'?
> Maybe we could think about having a '--strict' flag that does what you mean,
> but excluding the current behaviour is not acceptable in my opinion.
>   
In the following example:

@  6:c3ea4ca155f6  Fix bug 101 - risky
|
o  5:be078eacff11  Fix bug 100, part 2
|
| o  4:35e3685137e8  Add feature X
|/
o  3:95ffd5131b39 Fix bug 100
|
| o  2:4390bd84d30b  1.0 RC-2
| |
| o  1:66b802ab3be7  1.0 RC-1
|/
o  0:4a2df7238c3b  Freeze before 1.0

When one picks revisions between 95ffd5131b39 and be078eacff11 
inclusively, one wouldn't expect for  35e3685137e8 to be included, as it 
is not between these revisions in the graph.

In another clone of the same repository, the revisions may be arranged 
like this:

@  6:c3ea4ca155f6  Fix bug 101 - risky
|
| o  5:35e3685137e8  Add feature X
| |
o |  4:be078eacff11  Fix bug 100, part 2
|/
o  3:95ffd5131b39 Fix bug 100
|
| o  2:4390bd84d30b  1.0 RC-2
| |
| o  1:66b802ab3be7  1.0 RC-1
|/
o  0:4a2df7238c3b  Freeze before 1.0

One would expect a command to cherry-pick revisions between 95ffd5131b39 
and be078eacff11 to behave the same in both cases.