1

I made a fork of a GitHub repository. I fixed a bug, wrote a test and created a pull request which was merged into the original repository.

So far, so good.

Now I improved the test on my local machine. I want to create a new pull request with this improved test. But in the meantime, other commits have been made to the original, upstream repository. So I want to get my fork into sync with the upstream repository so that I can create the new pull request.

Without fully grasping what I was doing, I've been copy/pasting git commands from other StackOverflow answers. But I can't get it to work.

Here is what the situation currently looks like:

$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use

    git push origin HEAD:<name-of-remote-branch>
$ git status
rebase in progress; onto 4378fa4
You are currently rebasing branch 'master' on '4378fa4'.
  (all conflicts fixed: run "git rebase --continue")

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        Tests/.vscode/

nothing added to commit but untracked files present (use "git add" to track)

Or visually:

$ git log --all --graph --pretty=format:'%C(auto)%h%C(auto)%d %s %C(dim white)(%aN, %ar)'
* 46f5c0e (HEAD) Change to non-UTF8 locale C (ASCII only) inside test (BioGeek, 3 hours ago)
| *   fe24176 (master) merge changes from upstream (BioGeek, 3 days ago)
| |\
| |/
|/|
* | 4378fa4 (upstream/master) Thank Jerven for ExPASy URL updates (Peter Cock, 3 days ago)
* | 03de45c Update ExPASy tests for HTTPS (Peter Cock, 3 days ago)
* | 47cdbf7 Move expasy URLs to https (Jerven Bolleman, 4 days ago)
* | 9bfb8b1 replace expasy.ch by expasy.org (Jerven Bolleman, 4 days ago)
* | 1a32c50 Determine encoding for urllib handles from HTTP headers (Jeroen Van Goey, 3 days ago)
* | ccf88fc Tests do not require postgresql CREATE DATABASE permissions (Adhemar Zerlotini, 3 days ago)
| | *   6b7d235 (refs/stash) WIP on master: 6311677 remove Doc/examples/tree1.nwk which was committed accidentally (created during testing?) (BioGeek, 3 days ago)
| | |\
| |/ /
| | * 4ead5fa index on master: 6311677 remove Doc/examples/tree1.nwk which was committed accidentally (created during testing?) (BioGeek, 3 days ago)
| |/
| * 6311677 (origin/master, origin/HEAD) remove Doc/examples/tree1.nwk which was committed accidentally (created during testing?) (BioGeek, 3 days ago)
| * 41ff4cc Address flake8 warnings (BioGeek, 3 days ago)
| * 815bbfd Add encoding and prefic unicode string with 'u' (BioGeek, 3 days ago)
| * 0e7451d If the handle has a headers attribute, then use it's content charset as encoding. Otherwise fall back to the default behaviour. (BioGeek, 4 days ago)
| * 6a7d05b Add test for correct handling of encodings in Entrez.efetch. Also add some missing docstrings in other tests and close handles everywhere (BioGeek, 4 days ago)
|/
* 4ccdace mmCIF parser fix to check for both '?' and '.' as unassigned values (Joao Rodrigues, 5 days ago)

Changeset 46f5c0e is the improved test from which I want to create a new pull request.

How do I get to sync my fork with the upstream repository so that I can create the new pull request?

msanford
  • 11,803
  • 11
  • 66
  • 93
BioGeek
  • 21,897
  • 23
  • 83
  • 145

1 Answers1

3

As stated in git's somewhat helpful error message:

$ git status
rebase in progress; onto 4378fa4
You are currently rebasing branch 'master' on '4378fa4'.
  (all conflicts fixed: run "git rebase --continue")

Continue rebasing

This means you have probably git pull -r from your upstream, or are rebasing a branch onto another branch locally, and you have encountered a problem while attempting to automatically merge (likely a merge conflict).

When git encounters a merge conflict while attempting to fast-foward, it stops rebasing and waits for the user fix the problem manually.

Once that is done, you need to stage the changed files you fixed (with git add <pathspec>) but not make a commit. Once the file is staged, git will be aware of your changes and attempt to integrate them when you git rebase --continue.

Keep fixing problems and git rebase --continue until you are done. This will move your HEAD to the tip of your working branch. You can then push.

Alternatively

You can git rebase --abort to abandon the whole thing, which will also undo any fixes you have made along the way, and try another merge strategy, like a 3-way merge.

One advantage of a three-way merge over a fast-forward is that all of the merge conflicts will be presented at the same time and you can create a new merge commit with all the fixes. While fast-forwarding, however, you may need to stop several times to fix conflicts as git encounters them while applying successive commits to your working branch.

My personal take

Given

Without fully grasping what I was doing, I've been copy/pasting git commands from other StackOverflow answers. But I can't get it to work.

I would git rebase --abort and start from scratch. If you stopped many times and had to fix many merge conflicts, you could use git pull --no-ff <remote-name> <local-branch> to explicitly instruct git not to try a fast forward, even if it can.

Last-ditch option

If the histories are just unmanageable and your change is small, you can always "shelve" your changes, meaning copy your version of the changed files to your desktop and then overwrite your local branch with the exact content of the upstream. Then, just copy the changed files back into your repo and make a commit.

It is not an elegant solution, but it works and is sometimes far easier than managing a long history. But you will lose the commits you had. There is a way to preserve them with patching, if you're really interested.

Further Reading

More on what detatched HEAD means.

msanford
  • 11,803
  • 11
  • 66
  • 93
  • 1
    Thanks, for the detailed answer! I have some reading to do so that I better understand what I'm doing, but I'll follow your advice of doing `git rebase --abort`. – BioGeek Oct 30 '17 at 14:41
  • @BioGeek My pleasure. I'm taking a couple of minutes to read [your fork](https://github.com/BioGeek/biopython) and see that your histories have indeed diverged `This branch is 7 commits ahead, 17 commits behind biopython:master.` A rebase is usually the appropriate solution. Perhaps just abort and try it again *with fast forward* (so `git pull -r master`) from a fresh start, fix conflicts, continue, and push. Then you can compare branches with biopython and see if it looks good. – msanford Oct 30 '17 at 14:43
  • 1
    @BioGeek As an aside, I have taken the habit both at my day job and in OS contributions to pull from upstream basically every time I sit down to start working in order to ensure the potential quantity of merge conflicts is manageable. Not always necessary at that frequency, but handy to do. – msanford Oct 30 '17 at 14:47
  • 1
    I managed to make the [pull request](https://github.com/biopython/biopython/pull/1434)! It still wasn't perfect (the git commit history gave merge conflicts), but we're making progress. :-) – BioGeek Oct 31 '17 at 14:20
  • 1
    @BioGeek Glad to hear it! My first few public PRs were a _complete_ mess, you're doing quite well. Git branching allows you to make test branches and do whatever you want with impunity, so just keep experimenting. – msanford Oct 31 '17 at 14:30