Equivalent to Mercurial's 'fetch'

Ben Finney bignose+hates-spam at benfinney.id.au
Fri May 30 14:05:52 BST 2008


Aaron Bentley <aaron at aaronbentley.com> writes:

> Ben Finney wrote:
> > In that case, I vote for a single 'merge --automatic' option that
> > would be like 'merge --pull' but with the added behaviour of
> > automatically committing a merge if the merge was successful.
> 
> merge --pull has very significant disadvantages.

What are those? From the description, it seems a fairly
straightforward combination of two existing commonly-used Bazaar
operations.

Bazaar seems to have all the information it needs to decide whether to
simply do a 'pull' or 'merge' before even beginning the attempt at
either.

> Requiring it as part of --automatic would make auto-commit option
> for most Bazaar users.

I don't know how I'm supposed to parse that sentence. Can you explain
a different way?

> However, it could certainly be supported as merge --pull --autocommit

Okay, so it sounds like you don't argue against the functionality
being available. I'm +0 on having the two options available
separately.

It seems, though, that the people who want a "automatically bring this
branch up to date with those revisions if possible" operation (e.g.
those who like the default behaviour of Mercurial's 'fetch' command)
would find such a command string too long.

For this purpose I'm proposing a 'bzr automerge' or 'bzr merge
--automatic' that does both of "automatically pull if possible" and
"automatically commit if possible", falling back to an
uncommitted-changes state only if manual intervention is impossible to
avoid.

That is, an interface issue, however that gets implemented. (Aliases?)




More information about the bazaar mailing list