2 ms·

mind explaining what hg push/pull do to a git only user? perhaps it's that i'm just only used to git's definitions of the words, but they seem symmetrical to m

mind explaining what hg push/pull do to a git only user? perhaps it's that i'm just only used to git's definitions of the words, but they seem symmetrical to me in the sense that they both try to synchronise history, either upwards or downwards. i can't really imagine what a pull would do differently than a merge or rebase that would satisfy the idea of synchronisation but be more symmetrical as you describe. i'd really appreciate an elaboration.

anton_gogolev 13y ago
"hg push" does nothing fancy: it just prepares a bundle [1] and sends it over to the server. The server can either reject (when committing a bundle will result in creation of a new head) or accept (either by virtue of --force flag or just because it does not create any new heads) the bundle and transactionally commit it to the repository. If the repository being pushed to is not "bare" (in Git parlance), it's working copy will not be affected by a push operation. Note that there's no merging going on here. All the merging/rebasing/rewriting happens before "hg push". Now, "hg pull" does perfectly symmetrical thing: it downloads a bundle from the server and commits it to the local repository. Working copy is not affected at all. Again, merging/rebasing happens elsewhere, outside of "hg pull" workflow. [1]: http://mercurial.selenic.com/wiki/BundleFormat http://mercurial.selenic.com/wiki/BundleFormat