Unable to get unified diff. fatal: bad revision "HEAD" on git diff for making the first commit

Question

I created a new repository in Gitlab. Then I created a folder and added a text file in it. I ran the following commands.

• git init
• git remote add origin https-path-to-repository.git
• Now I open the Tortoise git GUI and click "Check for modifications".It shows me the newly added file.
• Then I click on "Save unified diff" to create a patch.

However, it gives me this error Unable to get unified diff. fatal: bad revision "HEAD".

I need to create the patch and get it reviewed first before making the commit.

On my local system, it shows I am on master branch. Do I need to create one on Gitlab as well?

Answer 1

A new repository has no commits yet.

The git diff command most typically looks at:

• the difference between two commits, or
• the difference between some existing commit, and some set of files you're planning or proposing to use for a new commit.

Since you have no commits, neither of these is possible. Git can handle this case by just pretending there's a previous commit with no files in it, so that all files are added, but apparently Git handles this particular case better than TortoiseGit.

On my local system, it shows I am on master branch.

You are, and yet you also aren't. Git's branches—or more precisely, its branch names—are required to hold the hash ID (the commit number) of some existing, valid commit. As there are no commits yet, no branch names are allowed to exist.

Git still needs to know which branch name to create, once you create that first commit. After that, the branch name can exist. So Git remembers that you're on master even though master doesn't exist yet.

Do I need to create [a branch] on Gitlab as well?

The repository on GitLab is presumably also completely empty.

If they do have commits

If it's not completely empty, you should connect your Git to their Git now and obtain, from them, all of their commits:

git fetch origin

so that you can add your new commit atop their existing commits. Unfortunately, things could get a little messy at this point; I have no idea how TortoiseGit will handle this. In command-line Git, you'd now run:

git checkout master

and then git add your new file. Note: If they don't have any commits, git checkout master would just fail here (and git fetch origin won't have done anything). This entire section is not useful, and you can ignore it.

An easy way to work around the "first commit" problem

GitHub and some other hosting companies encourage you to make an initial commit that contains only a README.md (and/or license) file. The readme file describes what your project is about. This also provides an initial commit, so that tools and GUIs like TortoiseGit don't need to special-case the fist commit.

Answer 2

UPDATE - the suggested fixes here all assume the origin repo is also empty; I see, though, that your question doesn't really say if that's true or not. If not, torek's answer has some important information, because you don't want to create a new root commit in that case. The remainder of this answer applies if the origin repo is also empty.

---

Some tools know that if you try to diff the root commit they should compare against an empty tree; some don't. Apparently this one doesn't.

Easiest fix is to create an empty commit before your commit.

git rm --cached -r :/:
git commit --allow-empty -m'Empty initial commit'
git add :/:

If red tape wants to prevent even that, then you may have a few options (depending on how red the tape really is):

1. Go ahead and do it locally to produce the patch for review, but then squash away the empty commit before pushing. That way you never push any commit that hasn't had its patch reviewed, so maybe that will make some bureaucrat smile.

2. Use a different tool to produce the patch. Farily sure the git command line tool could create the patch you want (check out git diff docs; https://git-scm.com/docs/git-diff)

3. If you've gotten this far down the list, you really need to have a talk with whoever is making the rules, because at the end of the day they need to understand that rare-but-required edge cases do exist.