NPE: Failed to get commit HEAD about gitblit HOT 13 CLOSED

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

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.

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.

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

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.

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)

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.

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.

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.

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.  :(

Issue 299 has been merged into this issue.