Checkout existing branch to established workspace (.moved)

Colin D Bennett colin at
Thu Mar 29 20:15:49 UTC 2012

Hash: SHA1

On Thu, 29 Mar 2012 14:40:09 -0400
Aaron Bentley <aaron at> wrote:

> Hash: SHA1
> On 12-03-29 01:51 PM, Colin D Bennett wrote:
> > On Thu, 29 Mar 2012 13:26:54 -0400 Aaron Bentley
> > <aaron at> wrote:
> >> On 12-03-29 12:05 PM, Colin D Bennett wrote:
> >>> Does the shelf live in the branch, or in the working tree as
> >>> it does today?
> >> 
> >> It lives in the branch.
> > 
> > That's exciting, but also concerning.
> > 
> > That's good in a lot of ways, especially since I generally
> > consider a checkout to be “throwaway” and not “precious”.  By
> > that I mean, if a checkout is clean, you can delete the
> > checkout without losing any information.
> Also, bzr zap --store will store uncommitted changes on the
> per-branch shelf and then delete your checkout.
> > But does that complicate things? What if you push or pull a
> > branch with shelves?
> Currently, per-branch shelves don't propagate through push and
> pull. They are oriented toward the local workflow.

OK, thanks.

> > One way that I often use shelves is if I start on some small
> > piece of work that might be a one-liner, I start out right in a
> > checkout of trunk without creating a feature branch as I
> > generally do.  So, in this checkout of trunk, I start making
> > the change to the working tree, and realize I've had to make
> > significant changes to stuff, so I want to switch to a new
> > feature branch for the work. I will do a 'shelve', then 'switch
> > --create-branch FEATURE' and then 'unshelve'.
> What is the benefit over simply 'switch --create-branch FEATURE'?

Um.... none.  I described the wrong scenario.  It's more for
switching between existing branches, particularly when I want to
make sure the 'switch' doesn't trash my work due to automatic
merges and possible conflicts.  If I shelve, switch, and unshelve
- --keep, then I avoid the possibility of conflicts.

> > Will that work if shelves are stored in the branch instead of
> > working tree?
> I don't think the per-branch shelves can replace normal shelf
> activities.  There is only one per branch, and they are managed
> automatically by the switch-pipe command.  Calling them 'shelves'
> can be misleading, since it implies you might "shelve",
> interactively edit changes, and then explicitly "unshelve"
> later.  In Pipeline documentation, I refer to them as "stored
> changes", instead.

OK, now it makes sense.  Perhaps “scratch pad” describes them.

Coming back to the original issue of getting your forgotten
uncommitted changes hosed by automatic merge during a switch, I
guess I would still just like 'switch' to abort by default if there
are uncommitted changes.  And have an option to override this and
switch anyway, like switch --uncommitted.

Version: GnuPG v1.4.11 (GNU/Linux)


More information about the bazaar mailing list