Equivalent to Mercurial's 'fetch'
aaron at aaronbentley.com
Fri May 30 14:29:53 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar