Equivalent to Mercurial's 'fetch'

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Finney wrote:
> 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.

Yes, and those operations should not be used in the same situation.  If
you have a branch that you usually merge into, pulling will change your
revnos and lose your local view of history.  Log will start showing what
it would show on the other branch; your changes will be shown as merges
into that other branch, instead of showing your changes as primary, with
merges *from* the other branch.

Merge is good.  It's for situations where you have diverged.

Pull is good.  It's for situations where you are updating a mirror.

merge --pull is not recommended.

>> 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?

If you tie auto-commit to merge --pull, then no one who thinks merge
- --pull is bad (which is most people) will be able to use auto-commit.

> 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.

We have user aliases for things like this.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIQAFR0F+nu1YWqI0RAv8XAKCJtn++GkV+Df57timQv5T4NAJhxgCfdcf8
hjKpuUBBcgtOsepHR7mLRqA=
=R0E5
-----END PGP SIGNATURE-----