Checkout existing branch to established workspace (.moved)
Colin D Bennett
colin at gibibit.com
Thu Mar 29 20:15:49 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 29 Mar 2012 14:40:09 -0400
Aaron Bentley <aaron at aaronbentley.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 aaronbentley.com> 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.
> > 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the bazaar