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.

1 Answer 1

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.

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 :) Apr 7, 2015 at 18:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.