2

I have forked the interleave package.

I made certain commits in my fork but now I want to discard them. I added the remote upstream branch (master branch by the interleave author), fetched it and rebased to upstream/master.

But now the magit status shows the below:

Local: master ~/.emacs.d/elisp/interleave/ Remote: master @ origin (http://[email protected]/kaushalmodi/interleave) Head: 5a9e4ce Refine docs Tag: v0.4.0 (8 ahead) Unpulled commits: 3b836ef Merge branch 'master' of http://github.com/kaushalmodi/interleave a297270 Merge org sorting fix from upstream 7a855c3 Fix the org-sort-entries issue 57b68fd Merge branch 'master' of http://github.com/kaushalmodi/interleave 39b872a Merge org sorting fix from upstream 88857ea Fix the org-sort-entries issue 9e53d4b Merge org sorting fix from upstream 50939fa Fix the org-sort-entries issue

The above shows my recursive failed attempts to do a clean rebase.

How do I get rid of those Unpulled commits so that the fork master commit hash matches with the original master commit hash?

I have already tried the git reset --hard <upstream master commit hash> method as suggested in this SO thread but that did not help; I simply want to get rid of all the unpulled commits so that I can do c c in magit.

Improve this question

1 Answer 1

Reset to default
5

By doing a hard reset locally you only discarded the commits locally. To make the commits go away on your public fork also, you have to remove them there too. Since you haven't done so yet, and your local branch tracks the respective branch on your fork, the commits you have discarded locally show up as unpulled commits.

To remove the commits on the remote too you have to do a forced push, using P - f u.

(Note that one should usually push to the push-remote instead of the upstream. To force push to the push-remote use P - f p.)

Note that one usually should not change published commits. But since this is your personal fork, most likely nobody based any work of their own on it, the commits are basically mistakes (as opposed to generally good changes with a defect; or so I assume from what you said), the history contains git usage mistakes, and this all happened recently, I would say that it is okay to just nuke the mess.

If you would actually like to keep the changes (but just once, and possibly after further improving them), then start by creating a new branch starting at what is in origin/master, and only then force push. Then show the log and cherry-pick the appropriate commits using A in the correct order.

You should also not name your fork origin, that should be used for the upstream repository. I usually use my username as the name of my public fork.

Improve this answer
1
  • P -f P did the trick! Thank you! Now on to figuring out how to change my fork name from origin to something else :) Commented Apr 7, 2015 at 18:16

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.