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