[rfc] 'bzr missing' for checkout could use master branch for comparing histories

[Martin Pool]

On  1 Aug 2006, Alexander Belchenko <bialix at ukr.net> wrote:
> Erik Bågfors пишет:
> >>> One risk with this is that people may omit '-n' and update when they
> >>> don't want to.  I think it's a tolerable risk, and no unrecoverable 
> >>data
> >>> is lost.
> >>
> >>Not true.  Update will perform a tree merge of the upstream revision and
> >>the local, uncommitted changes, and this merge can't easily be undone.

That's true.  I was a bit imprecise: that merge will not lose any
information, but it might mix it up a bit

> >Well
> >What would "bzr update -n" output? Anything?
> >it seams like -n is useles without -l or -v.  
> 
> It should not to be useless. I think 'bzr update -n' should print what 
> action it want to do.

Yes, I agree - and also it should fail if the real update would fail,
e.g. if you cannot push or pull because of divergence.

> >>I suppose one option would be to take it in the opposite direction, and
> >>create a 'preview' command, with subcommands for merge, update, etc.
> >>
> >>e.g. bzr preview merge * ~= bzr merge --dry-run *
> 
> I think it's overcomplicated.

That's an option.  But really the general style for bzr and for unix
commands is that modified behaviour is done by giving dash-options after
the main command, not prefix words.  (As compared to say vim where you
can say ':vertical split foo')

-- 
Martin