[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