Submitting+work

To submit your homework and your projects, you have to go through a kind of zany series of steps that might seem opaque and confusing. If you follow the instructions on this page, you should get a better idea of what you're doing and be confident that you are submitting all your work.

I don't expect you to necessarily go through all these steps (which are just used to check your submissions) each time you submit work; however, I recommend you go through them a few times until you get a handle on how git works and are sure you're taking all the appropriate steps each time.

Check for loose ends
Make sure that all the files you worked on have been checked into git. To do this, run

code git status code

Which might output something like:

code code
 * 1) On branch sine
 * 2) Changes to be committed:
 * 3) (use "git reset HEAD ..." to unstage)
 * 4) new file: sine.c
 * 5) Changes not staged for commit:
 * 6) (use "git add ..." to update what will be committed)
 * 7) (use "git checkout -- ..." to discard changes in working directory)
 * 8) modified: main.c
 * 9) Untracked files:
 * 10) (use "git add ..." to include in what will be committed)
 * 11) a.out
 * 12) sine.h
 * 13) sine.o
 * 1) (use "git add ..." to include in what will be committed)
 * 2) a.out
 * 3) sine.h
 * 4) sine.o
 * 1) sine.o


 * 1) I have one file that is "staged" and will be committed the next time I run "git commit" (sine.c).
 * 2) I have one file that has been modified since my last commit, but is not staged (main.c); if I run "git commit", it won't be included!
 * 3) I have 3 files that have never been committed and won't be until I add them (a.out, sine.h, sine.o).

I want to make sure all my source files are committed. That means I need to add main.c and sine.h. a,out and sine.o are generated files, so I don't need to add or commit them,

code git add main.c sine.h code

Now if I run "git status" the output is:

code code
 * 1) On branch sine
 * 2) Changes to be committed:
 * 3)   (use "git reset HEAD ..." to unstage)
 * 4)    modified:   main.c
 * 5)    new file:   sine.c
 * 6)    new file:   sine.h
 * 7) Untracked files:
 * 8)   (use "git add ..." to include in what will be committed)
 * 9)    a.out
 * 10)    sine.o
 * 1)    a.out
 * 2)    sine.o
 * 1)    sine.o

So we know that we are ready to commit. We do so:

code git commit -m "last changes to sine code" code

And now our "git status" shows that we don't have any outstanding changes:

code nothing added to commit but untracked files present (use "git add" to track) code
 * 1) On branch sine
 * 2) Untracked files:
 * 3)   (use "git add ..." to include in what will be committed)
 * 4)    a.out
 * 5)    sine.o
 * 1)    sine.o

In my repository, I have the file .gitignore defined so as to ignore files with file extensions .out and .o (and many others), so they won't so up as untracked files and the output when you run "git status" may be even cleaner.

Get updates from the master repository
This stage is not absolutely necessary, but it really helps ensure that your code works smoothly against my test scripts. If I've changed something, it would be a good idea for you to know about it.

Pull code from my master branch into your current branch. code git pull origin master code

This should go smoothly, and either announce "Already up-to-date." or pull some files and merge them into your branch. In rare cases, you might have committed changes to something that I also changed; this is bad, and we try to avoid it, but if it happens, you will get a message like:

code ... Auto-merging makefile CONFLICT (content): Merge conflict in makefile ... Automatic merge failed; fix conflicts and then commit the result. code

This is still manageable, but at this point you have to take the right steps or untangling the problem gets confusing. Git modifies the conflicted file; in this case, "makefile", and it will now have one or more sections that look like

code <<<<<<< HEAD sine : my_sine.c sine.h gcc -o sine my_sine.c

=
sine : ref_sine.c sine.h gcc -o sine ref_sine.c >>>>>>> 12f2e2f9edc92ad3b9be63729ef142850f315b7f code

Aha! This is where the problem(s) is/are. To fix this, you need to go into the file and replace each of those sections with the code you want (remove everything including the <<>>, and leave just your code). Now, run "git add " (with replaced by the conflicting file names; in this case, "makefile"). You've now overwritten my changes.

Check your status again ("git status") and commit if there are uncommitted changes.

Create a patch
Now that you know everything has been committed, patch your code against mine. To eliminate confusion about branches, go ahead and patch directly against my code, rather than one of your branches:

code git format-patch origin/master --stdout > wimberly-hw3.patch code

Now you should have a patch named "wimberly-hw3.patch" in your current directory. By the way, replace "wimberly" with your own **last name**, in lower case.

Assuming the followed the steps above, this patch should be good, but we should check it.

Check for patch errors
We can look directly at the patch (just open it up in a text editor, or use "less"). You should see a long history of commits with your name on them, and fragments of code both big and small.

But even better, you can test what applying your patch does. Clone a new copy of my repository //outside your git tree//, go inside it, and then apply the patch yourself.

code cp wimberly-hw3.patch ~ cd ~ git clone ssh://hughw@login.cs.nmt.edu/~cse221/docs.git testpatch cd testpatch git am ~/wimberly-hw3.patch code

This is exactly what I do when I get your patches. The last command applies your patch to a new tree, and should complete without errors. If you get a message saying there was a conflict or merge errors, then I won't be able to apply your patches to test your work! Go back to your tree and follow all the steps above to generate a new patch that will cleanly apply.

Check for working code
Now that you've ensured your patch //works//, you need to check that it really contained all that you want. Staying in this new repository that you just patched, look for the code you wrote. Try compiling it and running your test cases (which you should have included in your patch). If they don't succeed, you probably forgot to commit some code; look for anything that's missing and make a new patch that includes it.