Regarding your first question: Yes, you can also `git checkout -b newbranch`, rather than stashing the changes and then stashing them into a new branch; I just tend to stash my changes whenever I see that there&#x27;s updates on the parent repository. Call it a reflex.<p>Of course, you can also commit your changes and then `git branch`, which sounds insane (that commit is also now on the master branch!) until you remember that branches in git are just Mercurial&#x27;s pointers-to-heads. This means that you can, on the master branch, just `git reset --hard HEAD~4` or so (if you want the last 4 local commits to be on the new branch and you haven&#x27;t pushed any of them to the central repo), and your repository is in the state you want it in, as well. (And you&#x27;ll need that last step even if you `git checkout -b`, I think.)<p>Regarding your second one, Mercurial&#x27;s simplified model is actually really smart. You have to understand that Git complects two different things into `pull`: updating the repository in .git&#x2F; and updating the working copy from the repository. In Mercurial these are two separate operations: you update&#x2F;commit between the working copy and the repository; you push&#x2F;pull between two repositories. The working copies are not part of a push&#x2F;pull at all. So if you push to a repository with uncommitted changes in its working copy, <i>that&#x27;s fine</i>. The working copy isn&#x27;t affected by a push&#x2F;pull no matter what.<p>With that said, if that foreign repository has <i>committed</i> those changes, Hg will object to your push on the grounds that it &#x27;creates a new head&#x27;, and it will ask you to pull those commits into your copy and merge before you can push to the foreign repository. (The manpages also say that you can -f force it, but warn you that this creates Confusion in a team environment. Just to clarify: a &#x27;head&#x27; is any revision that has no child revisions. In the directed acyclic graph that is the repository history, heads are any of the pokey bits at the end. You can always ask for a list of these with `hg heads`.)<p>&quot;OK,&quot; you say, &quot;but let&#x27;s throw some updates into the mix, what happens? Does it nuke my changes?&quot; And the answer is &quot;no, but notice who has the agency now.&quot; Let&#x27;s call our repositories&#x27; owners Alice and Bob. Alice pushes some change to Bob&#x27;s repository. Nothing has changed in Bob&#x27;s working folder.<p>Now if Alice tells Bob about the new revision, Bob can run an update, if he wants. Bob has the agency here. So when the update says, &quot;hey, those updates conflict, I&#x27;m triggering merge resolution&quot; (if they do indeed conflict), he&#x27;s present to deal with the crisis. Git&#x27;s problem was precisely &quot;oh, we can&#x27;t push to that repository because we might have to mess with the working copy without Bob&#x27;s knowledge,&quot; and it&#x27;s a totally unnecessary problem.<p>Bob can also keep committing, blithely unaware of Alice&#x27;s branch, if Alice doesn&#x27;t tell him about it. The repository will tell him that there are &#x27;multiple heads&#x27; when he creates a new one by committing, so in theory he&#x27;ll find out about her commits -- though if you&#x27;re in a rush of course you might not notice.<p>Bob can keep working on his head with no problem, but can no longer push to Alice (if he was ever allowed to in the first place), because his pushes are not allowed to create new heads either. In fact he&#x27;ll get a warning if he tries to push anywhere with multiple heads, because by default it will try to push all of the heads. However he can certainly push his active head to anyone who has not received Alice&#x27;s branch, just by asking Hg to only push the latest commit via `hg push -r tip` -- this only sends the commits needed to understand the last commit, and as long as that doesn&#x27;t create new heads Bob is good to push.