Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You need to fix 2 issues</p> <p>1.) Revert the incorrect "facebook" commits that you pushed to the "master" branch of the upstream repo.</p> <p>The easiest way to do that might be to clone the repo from upstream once more into a new directory. Use e.g. gitk to see what are the wrong commits in the master branch, revert them and push them. Now your colleagues are happy because the wrong stuff in the repo are corrected.</p> <p>Don't use push -f unless you and all your colleages understand fully what you are doing. You might lose data. Reverting might look uglier but it is safe even if you get it wrong on the first attempt.</p> <p>2.) Fix your own repo, so that branches are no longer confused. The easiest would actually be to forget about the old repo and just continue with the new clone. However, if there are important stashes or other branches that have not been pushed to any upstream, then you need to repair the setup of your old repo. The easiest might be to edit .git/config directly. Take a clean repo that did not have such accidents as a sample if unsure what it should look like.</p> <p>Personally I often prefer <code>git fetch</code> over <code>git pull</code>. I don't think <code>git fetch</code> can fail. Git pull does a fetch and a merge in one command, sometimes it is just better doing the one be one In the remote branches remotes/origin/branchname you have exact snapshots of what is in the remote repo at the time of the last fetch. They are read-only, so you can never screw them up. (They are called remote, but they are not stored remotely, that is often misunderstood) Your local branches are read/write. If one is screwed up you can even delete it, and check it out again. Git will create a new local branch from the remote branch. (If course you don't want to delete a branch if it contains important commits that have never been pushed)</p> <p>Before doing tricky operations to your repo, which you don't fully understand, a backup might be a good idea, especially if you have something that has never been pushed.</p> <p>Myself I only use <code>git push</code> (without any arguments), so such mix-up cannot happen. (Except the first time I push a new branch.) Additionally I only use <code>git fetch</code> instead of <code>git pull</code> so it always succeeds and I can check what others have done. (but then I need to merge the remote branches changed if I maintain a local one for them, there a similar mix-up could happen, but still it would only be local and could be deleted without disturbing others)</p> <p>Addition: The accepted answer in <a href="https://stackoverflow.com/questions/18922702/git-pull-doesnt-do-a-git-fetch">Git Pull Doesn&#39;t Do A Git Fetch</a> gives further details about push/fetch/pull and how (not) to use them.</p>
 

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