[Extension] Dirty hack of 'shelve' and 'unshelve' command

[Michael Ellerman]

Hi all,

Thanks for all the comments, haven't had time to read through them til now 
owing to a trip to Brisie for a wedding.

Apologies for the shot-gun reply.

* I agree (Martin) that pre-checkin tests are "a good thing", for lots of 
reasons, not least that they encourage the developement of tests! But as a 
kernel hacker they're not really a good solution - unless someone can write 
me a testsuite which scrounges the right hardware for me, sets up the 
appropriate test network, powers on the machines ... I think you get my 
point.

* For a proper shelve we'd need to split hunks more aggresively, as you 
pointed out (Erik) the current bzr diff merges adjacent hunks which is not 
what you want for this feature.

* I don't see why you can't let the user edit a hunk (Aaron), and then 
recalculate the context and offsets. It's just a matter of getting the UI 
right. I think.

* I'd also like to see partial commit in bzr proper, but we can work on that 
later. I agree (Erik) that it is useful to review the changes you've made 
before you commit - I always run diff just before I commit to review for 
whitespace stuff ups and so on, so why not have commit do this for me. But I 
also think there's a place for a shelve command when you want to put a more 
major piece of work on the back burner and run some test for example.

* I don't think I understand you (Aaron) when you say "'unshelve' will restore 
the tree to the state it was in when you issued the 'shelve' command" - 
because I *don't* want it to do that. I want to shelve some stuff, maybe edit 
something, commit, make more changes .. blah, then unshelve and keep working.

I also don't want commit to unshelve, because then I might commit, make 
another unrelated change, commit => ouch I just commited my shelved patch 
without realising!

* (Aaron) I agree a 'shelve --all' would be good, I'd also like to replicate 
more of the darcs features in the prompting (like "shelve all changes to this 
file" - "shelve all remaining changes" etc.)

* As to a "proper" implementation of shelve (Aaron), I think I agree your 
option d) sounds the most promising. I haven't really worried about it yet 
though, I just wanted to explore how the user experience would be. 

A shelf really is just a micro-branch in the current repo with some UI wrapped 
around it to hide that fact - but that doesn't mean we have to implement it 
that way. On the other hand if it is implemented that way there might be 
other "fun/interesting" things we can do for the user.

* And yes (Magnus), one of the uses of shelve is to turn a revision history 
with stuff ups and debug code and so on into a series of nice patches for 
LKML or likewise.

cheers all

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person