NullPointerException when git repo is brand new (no commits)

[fredcooke]

[ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.1.2:revision (default) on project abc: Execution default of goal pl.project13.maven:git-commit-id-plugin:2.1.2:revision failed. NullPointerException -> [Help 1]

This is on 2.1.2, 2.1.3 didn't make it to me yet. Maybe you don't care. Pretty obscure use-case :-) Feel free to close wont-fix if you like. Just wanted to document it.

[ktoso]

I think it may be hard to decide just from the code if it's a "should panic" situation or "no git repo yet".

You can use <failOnNoGitDirectory>false</failOnNoGitDirectory> to not die on such repository.
But it may be easier to just commit "initial commit", with anything - like we discussed online.

If anyone else has ideas - please share them here :)

[fredcooke]

Git itself prints HEAD and then dies. I agree that some might want it to die, and others (me!) might want it to live. Seems too unimportant to add an option for? "die if repo empty" default == true? If not dying, you could use HEAD or EMPTY or something to signify it. The git dir IS there, just the contents don't make sense. Which is different to no git dir at all.

fred@cheetah:~/test$ git show
fatal: bad default revision 'HEAD'
fred@cheetah:~/test$ git rev-parse HEAD
HEAD
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

[wajiii]

I feel like 'just commit "initial commit"' is a fine solution, but it does require the user to realize what the problem is. I can see this being confusing, especially for people who are new to git and don't really understand it in the first place, despite being competent enough to run Maven. Yes, they are out there. I have worked with some among their number.

Seems like it would be nice to avoid the NPE at that critical moment and maybe print a helpful message suggesting they make sure their repo is fully-formed; maybe even just point to a wiki page here describing what they can look for to see whether this is their problem, and how to get past it.

[fredcooke]

FWIW, this happens to to me almost daily, and it always takes me a second thought to realise why :-) Then I have to commit either everything, or just the pom, or whatever, then I have to amend that commit when I get to something that I really want to commit. It's not the end of the world, but it's definitely slightly annoying, especially if you make a lot of new repos from archetypes with this plugin in them ;-)

[TheSnoozer]

Well the NPE is still present with the latest jgit-version.

However the latest version of the plugin has two options to bypass any kind of exception:

<failOnNoGitDirectory>false</failOnNoGitDirectory>
<failOnUnableToExtractRepoInfo>false</failOnUnableToExtractRepoInfo>

I also reported the NPE to the jgit project:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=464177

Not sure if they will fix it. Nevertheless as far as I understand this issue, the problem back in the days was that there had been no way to bypass exception(s) and the execution has failed.
With the current version there are two options to bypass exceptions and therefore would like to close this issue.

Questions, comments, or concerns?
By the way thanks for reporting & trying to figure out what was going on :)

PS:
failOnUnableToExtractRepoInfo was introduced with #63
failOnNoGitDirectory was introduced with #26

[fredcooke]

Comments and thoughts:

1. The issue being present and open gives visibility to someone experiencing the issue. It could still be found if closed, however when I check for issues in a piece of software on github, I only check open ones before creating a new one.

2. Perhaps failOnUnableToExtractRepoInfo should close this? /me checks docs... No, not really, as it would allow other failures that I don't want just as one user stated in the linked issue.

3. I guess my original comment re closing still applies, however I'd prefer it if Konrad made the call and did the deed. Feel free to ignore, that's just my sentimental side coming through.

4. I appreciate the way you wrote your message, very polite and pleasant! :-)

[TheSnoozer]

Hi @fredcooke,
totally agree with you and only open issues gives visibility and somehow tells that there is still some work to do.
I was somehow in the motivation to close old issues and didn't thought about that maybe setting the failOnUnableToExtractRepoInfo-switch will also allow other errors to fly stealthy under the radar.
I will keep the issue open due to the fact that this is either a bug bug that needs to be fixed in the jgit-implementation or the git-plugin needs to avaoid the NPE and warn the User that he/she has to do a commit before...

4. Thanks :) I rather not rage through all issues. Sometimes just to recheck whats going on if the situation is unclear is a good idea...However I'm still a human and can make mistakes :)

[TheSnoozer]

Hi @fredcooke,
I added some code which will print out some nice error message when running the plugin with jgit.

However, when running the plugin with the native-git implementation I'll get the following error with a brand new repro:
fatal: No names found, cannot describe anything.

This error will be produced when executing "git describe". Unfortunately this command can fail with the same message under a lot of different conditions. All of them depending on the configuration of the git describe (the maven-git-commit-id-plugin allows user to configure some options of the describe).
At this stage and time and date I would say for the native git implementation

I think it may be hard to decide just from the code if it's a "should panic" situation or "no git repo yet".

I'll leave the issue open, but as far as I can tell right now for the native implementation it will be really hard to distinguish between failOnUnableToExtractRepoInfo VS failOnNoGitDirectory. Not sure if this also apply for jgit-implementation.

[GGGariKKK]

Hi @TheSnoozer
Is there a reason the issue is still open or it may be closed since the fix was merged long time ago?