Local commit and shelves (was: Experiences with Bazaar in a Commercial Environment)

Stefan Monnier monnier at iro.umontreal.ca
Wed Feb 22 16:36:12 UTC 2012


> I don't think so, but I don't have an implementation.  I think Bazaar
> can do better, specifically it could handle this with "implicit
> --local commits".  Bazaar would automatically commit the workspace,
> then merge that "implicit commit" with the incoming update commit(s).

I think we're on to something here: there is a problem in Bazaar's
handling of "lightweight branches" in that it should make them more like
real branches.
By "lightweight branches" I mean things like shelves, local uncommitted
changes, of things committed with "commit --local".
Some of the problems:
- after "bzr update", the "commit --local" commit is largely lost:
  There should be a way to name it, check it out again, diff against it,
  so as to be able to go back to the "before update" state.  I suspect
  that there is such a way already, but it's at least not obvious enough
  for this user.
- Even without "commit --local" if you have local changes, after a "bzr
  update" some of those changes may be largely lost because they
  generate such unmanageable conflicts that it's very difficult to
  recover the "before update" state.  So even if the user doesn't do
  a "commit --local" before "bzr update", bzr should do one implicitly
  as Stephen suggests, and provide a way to go back to that state.
  [ this reminds me that I wish the local branch kept track of the visited
    revnos, so I could do "bzr update; bzr diff -rbeforelastupdate" which would
    give me the changes I just pulled.  This is useful even if you
    don't have any local changes at all.  ]
- Shelves bit-rot, I have an old shelve here in an active checkout tree,
  and I have to do a lot of extra work in order to be able to do anything
  useful with that shelve, because "bzr unshelve" or "bzr
  unshelve --preview" gives me an unreadable mess of conflicts.
  I'd like to be able to see for example the actual patch the shelve
  holds (not relative to the current checkout tree but relative to the
  revid that was current when the shelve was made, so it isn't obscured
  by conflicts).
  

        Stefan




More information about the bazaar mailing list