Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You (and git) are doing it exactly as you should. You're not using git incorrectly; it's intended to be able to push and pull from different places just like this.</p> <p><strong>The reason git complains to you</strong>, is because it's required by the changeset model: Suppose on machine A, you made a commit with hash "abcdef". In order to be able to share changesets between the repositories, like you want to do, commit "abcdef" must be <em>exactly</em> the same, everywhere. On machine B, when you pull that commit into your local changes, it might put that commit into the history in some particular place, but it cannot <em>mix</em> that commit with your local changes. Doing so would produce commit "3dea12", which is entirely different.</p> <p>Git could try to mix your changes on the fly, like subversion does. Consider, though, if you had committed six times: now you have to merge six times, once for each (indivisible) commit applied on the other machine. Subversion gets around this by summarizing the changes in an all-in-all blob of a diff, which it then tries to put on top of your local changes. It works sometimes, but some of the merging gets kinda screwy and it <em>doesn't</em> let you keep the neat, changesets-never-change history that git offers.</p> <p><strong>To solve your problem</strong>, here's your pull strategy on machine B:</p> <pre><code>$ git stash # Set your uncommitted changes aside for a moment $ git pull # Pull in the new changes # &lt;resolve conflicts, if they happen&gt; $ git stash pop # Bring back your uncommitted changes, fixing ambiguous # merge pieces as necessary. </code></pre> <p>Basically, this is the, "don't worry, <code>git stash</code> isn't scary," strategy. :)</p> <p>I think it's important to notice that <em>you will have to merge</em>. Good development practices, keeping changes small and so on might make merges happen less often, but you will still have to merge sometimes.</p> <p>By the way, <strong>you <em>want</em> git to complain.</strong> If your working copy is clean (no stashes needed), you're mixing one history with another. Git will find the spots where you need to merge and ask you what to do. It's a pretty clear process. If it has to conflate those spots with local changes <em>as well</em>, the history would get very confusing. That would essentially be merging things from the past with things from "the future", which in this case is your uncommitted work (that will probably change!).</p> <p>In light of that, here's your other option:</p> <pre><code>$ git commit -m "..." # Commit your local changes, making them part of history. $ git pull # Clean working copy! (maybe merging required) </code></pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload