[rfc] 'bzr missing' for checkout could use master branch for comparing histories
mbp at canonical.com
Wed Aug 2 05:15:37 BST 2006
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
> >>> 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
> >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')
More information about the bazaar