Issue #281 open

P3D2::Shelve and unshelve extension support

Santeri Vesalainen
created an issue

It would be nice to have a shelve and unshelve support ( ) in MacHg.

I think it should be easy to use instead of having various options in it - only one //hardcoded// shelf available for the machg, in UI when you 'submit' shelve button -> unshelve button becomes active and shelve button becomes inactive and vice versa. Thus, logically when shelve-button was clicked then logic would be hg shelve --all --name machgonlydonottouchthis * And when unshelve-button was clicked then logic would be hg unshelve --name machgonlydonottouchthis

IMHO, shelving / stashing is actually more than a nice dvcs feature even with small teams, when used in a simple way eg. no multiple stashes / shelves.

Comments (6)

  1. Jason Harris repo owner

    I have long thought about how to do this. Since we have a GUI here we can do better. A lot better I think. I envisage this as a checkbox in the commit dialog, and a new menu item called shelve. When one does the "shelve" style commit, it basically does the commit and then updates back to the rev just before the shelve. Ie the shelved commit created a new branch but we are not on that branch. (It also labels the commit with eg a label or extra info being a shelved commit, or even simply adds SHELVED: .... to the name.)

    Then when you are at some revision and want to unshelve something it basically commits everything (creating rev A), then tries to rebase the shelved commit to the current tip (rev A) to create rev B. If there is no problem with the rebase, then we can go ahead and uncommit rev A and rev B, and leave the effective changes in the tree.

    This way shelved things would be always visible and use normal mercurial tracking.

    So anyone, want to create some patches for this?

    Cheers, Jas

  2. Santeri Vesalainen reporter

    Your suggestion was interesting, and while it was first hard to understand why it does not utilize hg shelve / unshelve extension, using shelved local repository branches might be even harder to mal-use than actual shelves.

    Should the shelved branches be pushable / pullable also, like any other branches?

    Some thoughts of pushing against '-' and for '+' :

    - If somebody has 'used' to shelve/stash something he/she might think at least it won't get shared from own local repo anywhere.

    - simpler

    + If we want to promote the common code ownership at least in exceptional need cases like (hacker is on vacation, sickness leave etc.) and when shared branch job needs to be taken care of by somebody else from the team

    + more possibilites (like example above)

  3. Jason Harris repo owner

    Hi Santeri!

    Good points!

    Yes, using shelve /unshelve extension means the UI has to get more complex for the user and it also runs the risk of merging problems / conflicts and allowing one to get into a bad-ish state (I have done this with MQ on a number of occasions. (Of course I can almost always get myself out of these situations but then again I am a power user as are all of the mercurial developers...). Considering the level of questions I get, I think its fair to say there are a lot of bright people using MacHg, but they are really using it as a tool. They want to get in, do their stuff, and get out without really learning too much about the fundamentals of what's going on. (This is of course absolutely fine since I do the exact same thing myself with dozens and dozens of other programs / systems / utilities.) However, this means that since MacHg is a GUI I want the whole process to be as smooth and error free as possible... Using the shelve extension directly could lead to problems (interestingly I just saw this link: )

    To elaborate on the UI issue, the question is how would using the shelve / unshelve extension directly work? (If one as to do this.) Would there be some flag, or highlighted bit somewhere that you have shelved something? What about other user shelves? General mq thing? etc. I had a detailed plan of how to do this all at one stage and a GUI for it that I did on paper but it was fairly complex with all sorts of drag bits from queues to repo's and stuff. However in using, MacHg I found I wasn't really using MQ to do anything much more than rebasing and a bit of history editing. (I still use it sometimes to edit commit messages (I need to add something to the UI to easily allow this change...) Whenever I do an experiment now I usually just commit the experiment and then alter / history edit it as needed. I will in fact sometimes do the shelve step manually. Ie commit the bit and then roll back to where I was before the commit so that bit is parked of in its own separate branch and then I later go and incorporate it into the main code... So using normal branching with specially marked commits would just use all of the standard machinery, be nice and visible and be fairly clear as to exactly what is happening.

    But you raise a very good question about the sharing of the shelved bits. I guess there should be a common preference item about this, or maybe a per repo preference item? The next question is what should the default be? Probably no sharing of shelved commits...

    But thanks, for your comments! Any other observations? :)

    Cheers, Jas

  4. Anonymous

    Thanks for your comments,

    -> I have no other observations, than concurring the question :

    To elaborate on the UI issue, the question is how would using the shelve / unshelve extension directly work? (If one as to do this.) Would there be some flag, or highlighted bit somewhere that you have shelved something? What about other user shelves?

    -> From those I'd prefer flag as the simplest solution. And About other user shelves case, because we are talking about simple to use tool MacHg, I'd see that user of the tool is not interested introducing multiple shelves into repo, unless he or she is using the commandline hg instead, and then he or she definetly needs to know what shelves to unshelve to where; power user, like any other mercurial developer, as you coined. Thus, I see only tiny conflicting possibility of having hard-coded stash for shelving and unshelving for the tool.

    I am for not sharing the shelve - like you seem to be also.

    About default question, Did you meant the default name of the shelve used by machg shelve / unshelve button? like machgonlydonottouchthisunlessyoufeelcompetentenough

  5. Log in to comment