bzr shelve should have --keep

[Per Johansson]

One use case of the git staging area is where you stage your basic implementation of a feature, but then continue to work and try some changes that might or might not make it in. bzr could emulate this much better if bzr shelve has a keep option, eg:

<Work on basic implementation>
bzr shelve --all --keep
<Try an optimisation, which didn't work out>
bzr revert ; bzr unshelve
bzr ci -m "Feature A"

Since unshelve does have --keep, that can be used as a workaround, though it unnecessarily modifies the working tree.

[Alexander Belchenko (bialix)]

Per Johansson пишет:
> Public bug reported:
>
> One use case of the git staging area is where you stage your basic
> implementation of a feature, but then continue to work and try some
> changes that might or might not make it in. bzr could emulate this much
> better if bzr shelve has a keep option, eg:
>
> <Work on basic implementation>
> bzr shelve --all --keep
> <Try an optimisation, which didn't work out>
> bzr revert ; bzr unshelve
> bzr ci -m "Feature A"
>
> Since unshelve does have --keep, that can be used as a workaround,
> though it unnecessarily modifies the working tree.

I agree. So, there is workaround already, but it will be nice to have
such feature.

[Vincent Ladeuil (vila)]

Well, what you exposed can be achieved with:
<Work on basic implementation>
bzr commit -m 'Feature A'
<Try an optimisation, which didn't work out>
bzr revert

But that doesn't allow committing the nice optimisation when it works ! So:
<Work on basic implementation>
bzr commit -m 'Feature A'
<Try an optimisation, which works out, so don't even mention the first attempt>
bzr uncommit
bzr ci -m "Feature A"

But anyway, --keep for shelve is a good idea and shouldn't be hard to implement.