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

Erik Bågfors zindar at gmail.com
Tue Aug 1 17:14:35 BST 2006


On 8/1/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin Pool wrote:
> > I find I almost always want to just know about the revisions on one
> > side (either --mine or --theirs).  The current default of showing both
> > makes it just hard to read the output.
>
> That's my experience, too.
>
> >  --verbose, -v            show which files will be changed
> >  --list, -l         show a list of revisions to be applied
> >  --dry-run, -n      just show what would be done
>
> Interesting.  I think that might work.
>
> > 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.

Well
What would "bzr update -n" output? Anything?
it seams like -n is useles without -l or -v.  So how about letting -v and -l be
 --verbose, -v            show which files will be changed
 --list, -l         show a list of revisions to be applied

(see, same text :) )
and let them both do dryrun automatically?


> 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 don't like that.

/Erik
-- 
google talk/jabber. zindar at gmail.com
SIP-phones: sip:erik_bagfors at gizmoproject.com
sip:17476714687 at proxy01.sipphone.com




More information about the bazaar mailing list