Skip to content

NullPointerException when git repo is brand new (no commits) #57

Open
Open
NullPointerException when git repo is brand new (no commits)#57
Assignees
ktoso
Labels
enhancement

Description

@fredcooke
fredcooke
opened on Dec 21, 2012

[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.

Activity

  1. ktoso commented on Jan 13, 2013

    @ktoso
    ktoso
    on Jan 13, 2013
    Collaborator

    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 :)

  2. ghost assigned
    ktoso
    on Jan 13, 2013

  3. fredcooke commented on Jan 13, 2013

    @fredcooke
    fredcooke
    on Jan 13, 2013
    ContributorAuthor

    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

  4. wajiii commented on Mar 29, 2013

    @wajiii
    wajiii
    on Mar 29, 2013

    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.

  5. fredcooke commented on Mar 29, 2013

    @fredcooke
    fredcooke
    on Mar 29, 2013
    ContributorAuthor

    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 ;-)

  6. TheSnoozer commented on Apr 8, 2015

    @TheSnoozer
    TheSnoozer
    on Apr 8, 2015
    Collaborator

    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

  7. fredcooke commented on Apr 8, 2015

    @fredcooke
    fredcooke
    on Apr 8, 2015
    ContributorAuthor

    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! :-)

  8. TheSnoozer commented on Apr 8, 2015

    @TheSnoozer
    TheSnoozer
    on Apr 8, 2015
    Collaborator

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

    1. 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 :)

  9. TheSnoozer commented on Apr 9, 2015

    @TheSnoozer
    TheSnoozer
    on Apr 9, 2015
    Collaborator

    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.

  10. TheSnoozer
    added a commit that references this issue on Apr 9, 2015

    Merge pull request #182 from TheSnoozer/master

    bf4adb6

  11. helitopia commented on Aug 24, 2023

    @helitopia
    helitopia
    on Aug 24, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancement

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions