Fixing Git Labs

Jan 26, 2024  β”‚  m. Jan 29, 2024 by Charlotte Curtis

This semester I tried setting up a new system for labs, and I botched it, resulting in what appears to be disappearing work. The good news is that your work is not gone, and I will help you recover it! Unfortunately I cannot go in and fix it for you, so there are a few extra steps on your part.

To start, cd into your labs repository.

Step 0: Commit any changes you have

Git will not allow you to cherry pick (or merge, or rebase, or just about anything) if you have uncommitted changes. The first step is thus to commit any modified files. You can check if you have any changes with git status, then add and commit them as usual.

As we’re usually editing multiple files, it can be easier to just add everything with git add . and then commit with git commit -m "message". This will add all modified files to the staging area, and then commit them with the given message.

Note: to date I haven’t been too picky about your commit messages, but as you’re about to see the message is quite useful! If all your messages are things like “done” or “commit”, it will be hard to tell which is which. Try to get in the habit of summarizing what you’ve done in each commit.

Step 1: Recover your lost commits

Git doesn’t like to truly delete things, so your work is still there, but it’s in a “dangling” state - it’s been cut out of your commit history. We can recover it with the help of git reflog and git cherry-pick.

  1. Run the command git reflog. This will produce a list of all the stuff you’ve done in the repository, including your lost commits. You should see something like this:

    $ git reflog
    4068f6e (HEAD -> main, origin/main, origin/HEAD) HEAD@{0}: pull --rebase (finish): returning to refs/heads/main
    4068f6e (HEAD -> main, origin/main, origin/HEAD) HEAD@{1}: pull --rebase (start): checkout 4068f6e6cb59267f347c603a9efd0b33712bf197
    a5761ae HEAD@{2}: commit: Completed functions lab
    b58a9f5 HEAD@{3}: commit: Adding intro lab
    4068f6e (HEAD -> main, origin/main, origin/HEAD) HEAD@{4}: clone: from /library/students/comp1633/labs.git/
    
  2. Find the commit you want to recover. In this case, I want the third item in the list with the message “Completed functions lab”.

  3. Copy the commit hash, which is the unique identifier for each commit (the string of random looking numbers and letters at the start of each line). You can copy from Windows terminal by selecting the text with your mouse and then pressing “Ctrl + Shift + C”.

    If you’re not sure which commit you want, run git log to see the ones that are in your history, and compare to the output from git reflog. The commits in reflog but not log are the ones that need cherry-picking.

  4. Restore the commit with the command git cherry-pick <commit hash>. In this case, I would run:

    $ git cherry-pick a5761ae
    

    You can paste in the terminal with “Ctrl + Shift + V”.

    Note: if copy/paste isn’t working for you, you can type the hash manually, or refer to it as HEAD@{2}.

  5. Verify that your work is restored! You can run git log to see your commit history, and open your files in emacs to see that your work is there.

  6. Repeat this step for each lost commit - for example, you may need to recover both your functions lab and your by_ref lab.

DO NOT PUSH CHANGES YET - we need to fix the configuration. It’s not the end of the world if you do, it just means you’ll have to redo the cherry-pick stuff.

If you’d prefer a video version of this process, check out:

Step 2: Fix your configuration

I’ve updated git-asg-config so that this will hopefully never happen again. To fix the configuration, re-run it. I’ve included the steps here for convenience, but it’s the same interface as before.

  1. Run the configuration script:

    $ git-asg-config
    

    and follow the prompts for your instructor’s username, course name, and section number as before:

    FieldValue
    Instructor’s user nameccurtis or mkarimifatemi
    Course namecomp1633
    3-digit section name001 or 002

    Note that the assignments are listed alphabetically, so you should now see something like this:

    Choose what to configure:
        1      a1
    
        2      labs
    
    
    (Press [F1] for HELP)
    
    ([ESC] to Quit)   PLEASE ENTER A CHOICE:
    

    Enter 2 to configure your labs repository.

    This should produce the following:

    Configuring test_lab for labs, are you sure ([y]/n)? y
    
    Renaming remote references: 100% (3/3), done.
    --------------------------------------------
    Assignment configuration complete!
    Push your changes with `git push`, and fetch
    new content with `git pull`
    --------------------------------------------
    
  2. Run git push to push your recovered commits to the submit location. You should not need to specify --force anymore.

  3. Check your status! You should see something like the following:

     $ git status
     On branch main
     Your branch is ahead of 'teacher/main' by 1 commit.
         (use "git push" to publish your local commits)
    
     nothing to commit, working tree clean
    

    It’s okay that you’re ahead of teacher/main. Now, teacher refers to the starter code repository, and submit refers to your push repository.

    Note: git status will not tell you if you’ve pushed your changes, unfortunately - it can only be set up to track one repository at a time. You can run git push again to verify that it gives the message “Everything up-to-date”.



Previous: Git FAQ and Troubleshooting
Next: Midterm Trivia