[RFC] Moving uncommited changes from a tree to another.

[Martin Pool]

On  9 Aug 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > Aaron's 'shove' command is awesome, it works for me. I guess the only
> > problem with it vs a bundle approach is you need both trees
> > write-accessible at the same time. But it's a minor problem IMHO.
> > 
> > Actually I think it should be in the core.
> 
> Aw shucks.  Of course, the problem is trying to maximize the
> functionality while minimizing the number of commands to learn.  Shove
> is a very single-purpose tool.  But if other folks feel 'shove' should
> go in core, I can prepare that.

I didn't know of shove until it was mentioned here (or maybe Robert told
me about the same time.)  

I think it'd be good to bring in, though perhaps we can unify it with
something else.  Perhaps 'merge --uncommitted'?  Obviously it doesn't
generate a merge record but in other ways it might be similar?

I've been thinking more about plugins vs core.  I think I'm a bit more
in favour of things going in to core, for a few reasons:

 - slightly easier to find them
 - questions can be answered with "use bzr shove", rather than "use
   bzrtools shove, which you have to get from xxx and install by yyy"
 - in the process of coming in we can get more design, ui and code
   review
 - once it's in it will stay tested and maintained

There can be versioning drift - bzr 0.8.2 plugins won't work perfectly
with 0.9.

So I'd say plugins are approximately best for

 - when someone wants to experiment unconstrained (as with bzrtools
   perhaps)
 - when it's really site-specific
 - when it's integration with something else that many people won't have
   or want to use (editors etc)

And then there's a middle ground of standard plugins.

-- 
Martin