Using 'git pull' to Update an Assignment

Your instructor may update the provided code for a GitHub Classroom project to fix bugs, improve tests, etc. When this happens, you may want to update your project repository to include these changes. This document will help you accomplish that.

If you have not yet created your assignment in GitHub Classroom, you probably do not need to follow these instructions, as described in You have not yet created the assignment, below.

Overview

The git pull command combines two operations: fetching changes from a remote repository, and then merging those changes with your local repository. In order to pull from a remote repository that is not the origin of your local repository (a special remote repository that git creates for you when you clone), you will have to teach it about the remote repository that you want to use.

Adding a Remote Repository

You can pass a remote repository to the git pull command as a URL (e.g., git@github.com:ub-cse410bla-f18/malloc), but it is often desirable to refer to a particular remote repository many times, and git provides a way to manage remote repositories for this purpose.

If your instructor has updated a remote GitHub Classroom repository and wants you to merge it into your project, you should have been given a URL for this repository. We will refer to that URL as $URL in these instructions.

The git remote command manages remote repository URLs. You can view the list of remote repositories that git knows about with git remote -v, as follows:

[elb@westruun]~/work/buffalo/cse410/assignments/malloc$ git remote -v
origin	git@github.com:ub-cse410bla-f18/pa1-malloc-eblanton (fetch)
origin	git@github.com:ub-cse410bla-f18/pa1-malloc-eblanton (push)

This indicates that git knows about a remote repository nicknamed origin (as previously mentioned, git creates this repository for you on clone), and that it uses the same URL, which is a ssh URL, for both fetch and push operations.

What we are going to do is add a second URL named classroom for the remainder of the operations in this document. This will enable us to refer to the same remote repository repeatedly with a convenient nickname. To do this, issue the command:

git remote add classroom $URL

After running this command, the output of git remote -v should look something like this:

[elb@westruun]~/work/buffalo/cse410/assignments/malloc$ git remote -v
classroom	git@github.com:ub-cse410bla-f18/malloc (fetch)
classroom	git@github.com:ub-cse410bla-f18/malloc (push)
origin	git@github.com:ub-cse410bla-f18/pa1-malloc-eblanton (fetch)
origin	git@github.com:ub-cse410bla-f18/pa1-malloc-eblanton (push)

You can now refer to the remote repository at $URL using the nickname classroom for most git commands that accept a repository argument, including git pull.

Merge Possibilities

There are several possible scenarios that will be handled somewhat differently, depending on the state of your project repository and the changes the instructor has made to the provided code. They are:

• You have not yet created the assignment in GitHub Classroom. In this case, you should not need to take any special action. When you clone your repository normally, you will get the updates automatically before you even start work.

• You have created the assignment, but have not yet made any changes. This is easy to handle; simply run git pull classroom master and you’re done!

• You have uncommitted changes to your repository. In this case, I highly recommend that you commit your changes and then follow the instructions for committed changes to your repository, below.

• You have committed changes to your repository. Run git status to make sure that you don’t have outstanding uncommitted changes that you have forgotten to commit. Assuming it doesn’t show uncommitted changes to files that you care about, run git pull classroom master. This will attempt to merge the changes from your instructor. If git believes that it can do this cleanly, it will make the changes and open an editor (probably vi if you have not configured another editor!) for the commit message; simply save and quit, and you’re done. (To save and quit in vi, type :wq and press enter.)

You will see output something like this:

[elb@westruun]~/work/buffalo/cse410/assignments/malloc$ git pull classroom master
From github.com:ub-cse410bla-f18/malloc
 * branch            master     -> FETCH_HEAD
   9015e5e..21d5ba4  master     -> classroom/master
Auto-merging src/mm.c
Merge made by the 'recursive' strategy.
 Makefile | 7 ++++---
 src/mm.c | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

At this point you should be good to continue development.

The other possibility is that there will be something git believes it cannot merge automatically. If this happens, don’t panic! That’s exactly why you committed before beginning your merge. Follow the instructions under Resolving Merge Conflicts, below

Resolving Merge Conflicts

Sometimes git cannot figure out how to incorporate the changes in a remote repository with the changes in your local repository. In this case, it will notify you that you have merge conflicts with a message like this one:

[elb@westruun]~/work/buffalo/cse410/assignments/malloc$ git pull classroom master
From github.com:ub-cse410bla-f18/malloc
 * branch            master     -> FETCH_HEAD
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
Automatic merge failed; fix conflicts and then commit the result.

In this case, git could not reconcile the upstream changes to the Makefile with the local commits that have changed it. We can see what git tried to do by opening up Makefile in an editor and searching for conflict markers, which are regions of text surrounded by <<<<<<<, >>>>>>>, and =======. In this case, suppose I find the following:

CC := gcc

# You may change this if you like.  However, the grader will use these
# CFLAGS!  Note that _DEFAULT_SOURCE must be defined for your source to
<<<<<<< HEAD
# find the functions brk() and sbrk().
CFLAGS := -g -Wall -Werror -std=c99 -DDEBUG_MM -D_DEFAULT_SOURCE
=======
# find the functions brk() and sbrk(), and -fPIC is required for
# building the shared library libcsemalloc.so.
CFLAGS := -g -Wall -Werror -std=c99 -fPIC -D_DEFAULT_SOURCE
>>>>>>> 21d5ba406597b220b27c86a4f84a9d25ebb0eb66

# These are the included tests.  You may modify this line if you like,
# but your modifications will not be submitted.  (You might, for
# example, want to temporarily remove tests that are known to fail.)
TESTS := tests/test_bulk

This indicates that the revision HEAD (my most recent commit) and the remote revision 21d5ba406597b220b27c86a4f84a9d25ebb0eb66 have a conflict in this comment and definition of the CFLAGS variable. The first block, starting with <<<<<<< HEAD and ending with =======, is what was present in my commits. The second block, starting with ======= and ending with >>>>>>> 21d5ba406597b220b27c86a4f84a9d25ebb0eb66, is what was present in the instructor’s repository update.

Examining this conflict, it looks like the instructor updated the comment (which I had not changed) and added the flag -fPIC, while I had added the flag -DDEBUG_MM. I can resolve this conflict by taking the instructor’s commit and adding -DDEBUG_MM to the CFLAGS line, resulting in the following text:

CC := gcc

# You may change this if you like.  However, the grader will use these
# CFLAGS!  Note that _DEFAULT_SOURCE must be defined for your source to
# find the functions brk() and sbrk(), and -fPIC is required for
# building the shared library libcsemalloc.so.
CFLAGS := -g -Wall -Werror -std=c99 -fPIC -DDEBUG_MM -D_DEFAULT_SOURCE

# These are the included tests.  You may modify this line if you like,
# but your modifications will not be submitted.  (You might, for
# example, want to temporarily remove tests that are known to fail.)
TESTS := tests/test_bulk

Having resolved whatever conflicts you find, you can commit the merge with git commit --all, which will present you with a commit message (see You have committed changes to your repository, above). A powerful feature of git (and other modern version control systems) is that, having resolved this conflict once, you should not see it again even if you merge future changes from the classroom repository.