GitLab @ UCSC

If you're having difficulty with GitLab @ UCSC, please read this page and follow the instructions before seeking help. Often, your problem can be resolved simply without asking others to help you.

IMPORTANT: this page is designed to help with errors that actually involve GitLab @ UCSC. Many git operations, such as git add and git commit are done entirely locally. If one of these commands fails, it has nothing to do with GitLab @ UCSC. Commands that do involve GitLab @ UCSC are listed below.

Types of errors

Password and permissions problems

Password and permissions problems are relatively common. The symptom of this is that you can't log into the Web interface or you're denied permission to clone or push on a repository that you should have access to.

If you need to reset your password, you can ask GitLab @ UCSC to send you a password reset email. Please make sure you check your spam box for the email in case it gets misfiled. Remember that it's sent to the email address you used to sign up (almost certainly your CruzID), unless you changed it on your account settings page.

You should also check to ensure that your SSH public key matches the SSH private key you have on the machine you're using. If you're not sure, you can manually compare them or just upload an additional key. This is often an issue if you switch to a new computer.

If you're having permissions problems, double-check the URL you're using to perform the operation. This is most common with git clone operations, since you may have mistyped the URL. Make sure you've changed the items that are supposed to be changed, unless your CruzID is actually cruzid.

Network issues

GitLab @ UCSC is run in one of UCSC's machine rooms, so it's unlikely to be unreachable via network unless much of campus is having network problems (which, sadly, is an issue with UCSC). It's much more likely that your local computer is having network connectivity issues. See if you can browse to UCSC's home page. If you can't, the problem is almost certainly with either your computer's network connection or the campus as a whole. If you can view UCSC's home page (make sure it's not cached!) but can't connect to GitLab @ UCSC, please contact your instructor and the GitLab admins.


Many cloning issues are discussed above, and stem from not typing the repository URL properly, or not using your chosen access method (SSH or HTTPS) properly.

You also might ensure that you have sufficient space on the system you're cloning to, and that you're attempting to clone into a directory that you have permission to write, and that isn't already a git directory. Bad things can happen if you clone into a directory already under git control. Fortunately, they're only local problems; you can always fix things by cloning a new copy of the repository from GitLab @ UCSC.


Often, problems with git push are really permissions problems. However, it is possible for GitLab @ UCSC to refuse to accept your repository push even if you have permissions.

In order to avoid students adding excessive (and unnecessary) files to their repository, GitLab @ UCSC runs a script on every git push. If this succeeds, the command line messages look like this: feather13:gitlab-ucsc-docs elm$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 761 bytes | 761.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
   ef4c3db..7139499 master -> master

Handling repositories that violate size limits

However, if your repository has exceeded the limits on total repository size, number of files, or size of one or more individual files, you'll get a message like this one: feather13:test-limits elm$ git push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 22.13 MiB | 13.64 MiB/s, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: ERROR: commit ebf8be3: total repo size (45361856) is too large (max size is 31457280)
remote: ERROR:
remote: ERROR:
remote: ERROR: ====> NONE OF YOUR COMMITS WERE PUSHED: your repo exceeds these limits
remote: ERROR: Maximum file size: 25.0MiB
remote: ERROR: Maximum repository size: 30.0MiB
remote: ERROR: Maximum number of files in repository: 200
remote: ERROR: ====> Please fix these problems and try your push again
remote: ERROR:
remote: ERROR: ==================================================================
remote: ERROR: If you believe your repo doesn't exceed the limits listed above,
remote: ERROR: please contact If you need help getting
remote: ERROR: your repo below the limits, please read the documentation
remote: ERROR: at If you're still having difficulty,
remote: ERROR: please contact your course staff.
remote: ERROR: ==================================================================
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to ''
Note the large number of error messages (the ones that start remote: ERROR:). In this case, the total repository size was too large in commit ebf8be3, as shown in the line highlighted in light yellow (immediately after the line with the word delta). The limit was 31457280 bytes (30 MiB), but our repository was over 40 MiB. The reason for this is that as we can see below, in commit ebf8be3 we added a big file to the repo, and then deleted it in commit 6fe0b79. This violates the repo size rules because the server would have to keep the data for that large file even though it's not in the repo for more than one commit. As a results, the push failed and none of the commits were pushed successfully to the server.

The way to fix this problem is to go back in time in your repository and not make the commits that caused the problem. The first step, before you do anything else, is to make a copy of your local repository. DO THIS FIRST!! If you accidentally make a mistake, you can always recover by going to the copy you just made. Now, follow these steps to fix the problem:

  1. Figure out where the problem first started. The error messages will contain commit IDs that exceeded the limits. Use git log to find the earliest such commit. For the above example, here's the last few entries in the git log --abbrev-commit --stat output: commit 41eea7b (HEAD -> master)
    Author: Ethan L. Miller <>
    Date: Mon Jul 2 18:41:08 2018

        More lines in small file

     small | 1 +
     1 file changed, 1 insertion(+)

    commit 488f136
    Author: Ethan L. Miller <>
    Date: Mon Jul 2 18:40:43 2018

        Added a tiny file

     small | 1 +
     tiny | 1 +
     2 files changed, 2 insertions(+)

    commit 4b8d135
    Author: Ethan L. Miller <>
    Date: Mon Jul 2 18:40:07 2018

        Removed large file A6X00574.DNG

     A6X00574.DNG | Bin 23222526 -> 0 bytes
     1 file changed, 0 insertions(+), 0 deletions(-)

    commit ebf8be3
    Author: Ethan L. Miller <>
    Date: Mon Jul 2 18:39:44 2018

        Added a large file A6X00574.DNG

     A6X00574.DNG | Bin 0 -> 23222526 bytes
     1 file changed, 0 insertions(+), 0 deletions(-)

    commit 4a366cc (origin/master, origin/HEAD)
    Author: Ethan L. Miller <>
    Date: Mon Jul 2 18:11:54 2018

        Added small2 back in

     small2 | 1 +
     1 file changed, 1 insertion(+)
    Note that ebf8be3 is the fourth entry down, and the fifth entry says, at the end, origin/master. This means that the server (GitLab @ UCSC) thinks that 4a366cc is the latest commit ID, and the local repository thinks 41eea7b is the latest commit ID.
    The problem happened in commit ebf8be3. As the log shows in the line highlighted orange, we added 23222526 bytes to a binary file A6X00574.DNG. The next commit (4b8d135) removed the file, as the line highlighted green shows. But the damage has been done: the repository is too large for one commit, and the server would have to store that data even though the file was removed in the next commit. That's why it rejected our attempted push.
    Complicating matters, we added a small file (tiny) in a later commit, and modified the file small in other commits. The server rejected those changes, too. We want to keep the changes in the small files!
  2. We need to go back to commit 4a366cc, since the next commit caused things to break. To do this, we use the following command: git reset 4a366cc This will reset the git history to this commit, but will leave all of the intervening changes in the directory, with one exception: files that were deleted in that time may stay deleted. In particular, newly-created files that were added to the repository will remain, and changes to existing files between the latest commit (41eea7b) and the commit you reset to (4a366cc) will still be in those files. They just aren't committed at this point.
  3. You can get a list of the (now uncommitted) changes in your repository with the git status command. Manually add back all of the modified files you want to commit and all of the new files you wanted to add to the repository in the commits that you rolled back over; they'll be listed in the output from git status. Do this by running git add file for each file whose changes you want to include or that you want to add back to the repo. In our example, we'll do: git add small
    git add tiny
    The first line commits allof the changes to small that we had made since commit 4a366cc, since the git reset left small the same as it was before the command was run. The second line adds the tiny file back that we had added in commit 488f136.
  4. Now, commit the changes you've made. git commit -m 'Added tiny to the repo. Updated file small.'
  5. Finally, push your changes to the server: feather13:test-limits elm$ git push
    Counting objects: 4, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (3/3), done.
    Writing objects: 100% (4/4), 363 bytes | 363.00 KiB/s, done.
    Total 4 (delta 1), reused 0 (delta 0)
        4a366cc..4fcdd41 master -> master
    Since we no longer have a repo that's too big, this works!

When all else fails...

If you've tried to solve the problem yourself and can't do it, please contact your instructor and the GitLab admins (gitlab-admin«at» Your email must include the following so we can help diagnose the issue:

Last modified (none) by Ethan L. Miller (elm«at»ucsc·edu)