NPE: Failed to get commit HEAD

[gitblit]

Originally reported on Google Code with ID 14

What steps will reproduce the problem?
1. start gitblit
2. open in a browser

What is the expected output? What do you see instead?
The system should display the usual summary page, but 
it instead fails with an internal error.

What version of the product are you using? On what operating system?
0.5.1, CentOS 5.5 x64

Please provide any additional information below.
gitblit used to work properly, but started failing today. I don't know which repository
is responsible for the issue, I am using gitblit to browse a server with about 80 git
repositories.

Commits are executed using standard git command line tool, tortoisegit and egit.

Reported by gm.romanato on 2011-07-22 14:35:29

---

- _Attachment: [log.txt](https://storage.googleapis.com/google-code-attachments/gitblit/issue-14/comment-0/log.txt)_

[gitblit]

I just realised that by calling directly the URL  */summary/?r=<reponame> I can access
the summary page of each repository.

I'll try to identify the offending repository and to understand the differences from
a working repository

Reported by gm.romanato on 2011-07-22 14:43:58

[gitblit]

Evidently my exception logging needs some, ahem, improving.  :)  Whatever you can dig
up would be super helpful.  In the mean time I will improve the logging and trap the
NPE.

Reported by James.Moger on 2011-07-22 14:48:59

• Status changed: Started

[gitblit]

Reported by James.Moger on 2011-07-22 14:49:12

• Labels added: Milestone-0.5.2

[gitblit]

The problem occurs on newly created repositories that do not contain any commit.
After making the first commit the issue disappears.

While not critical, this is a very annoying issue.

Reported by gm.romanato on 2011-07-22 15:04:39

[gitblit]

That is interesting.  This case should already be covered.  Are you creating the repository
with Gitblit or something else?

Reported by James.Moger on 2011-07-22 15:19:04

[gitblit]

Let me rephrase that question.

Does the exception occur on the main repositories list/root page?

Or are you trying to directly view a repository-specific page, like the summary page
by entering the URL manually?

If its the latter, then this is related to issue 309 where I do not allow browsing empty
repositories (which is by design).  The difference is in issue 309 you outlined a scenario
where my check for empty is flawed.

Reported by James.Moger on 2011-07-22 15:28:29

[gitblit]

hi, we create repositories using standard git on linux.
The repository was created but still no commit executed.

if you browse directly the repository summary page you get the stacktrace above, but
the same happens if you browse gitblit home (I mean the index of all repositories)

Reported by gm.romanato on 2011-07-22 15:32:24

[gitblit]

Nevermind.  I see you were access the repository list.
I think I have trapped this problem and the proposed fix will be in the next release.

Reported by James.Moger on 2011-07-22 15:34:13

[gitblit]

Another update. I realised that my colleagues already created a branch in that repository,
and committed code to the branch, but nothing has been committed to master.
This is because the repository is being migrated from another VCS, and devs working
on an unstable branch committed first.

Reported by gm.romanato on 2011-07-22 15:37:30

[gitblit]

That explains it then.

In 0.5.1 the isEmpty check looks for files in the refs/heads folder.  If no files,
its empty.  If has files it has commits.  That fails with your native Git bare clone
option which does not create any refs (interestingly JGit bare clone works - they must
define it slightly different).

The upcoming revised isEmpty check will determine if there are loose objects in .git/objects
or packed objects in .git/objects/pack.

Both of these approaches will fail, though with what you just described.  The silver
lining is that the next release won't break on the repositories page, though the "last
change" will be wrong as its based on HEAD - which of course is flawed design for branchy
models.  Something else to add to the TODO list.

I'll try to setup a test repository like you've described with no master to see what
else breaks.

Reported by James.Moger on 2011-07-22 16:00:34

[gitblit]

I think I've fixed the bug.  I also changed the "last change" bit to reflect branches,
not just HEAD.  Attached to this issue is snapshot of the upcoming release.  It also
includes adjustments for your other issues.

If you experience unusual slowness on displaying the repositories list, try disabling
the new setting web.showRepositorySizes.

I still can't reproduce your branch log issue.  :(

Reported by James.Moger on 2011-07-22 16:57:59

---

- _Attachment: [gitblit-0.5.2-SNAPSHOT.zip](https://storage.googleapis.com/google-code-attachments/gitblit/issue-14/comment-11/gitblit-0.5.2-SNAPSHOT.zip)_

[gitblit]

Issue 299 has been merged into this issue.

Reported by James.Moger on 2011-07-25 20:11:46

[gitblit]

Reported by James.Moger on 2011-07-27 12:14:40

• Status changed: Fixed