NullReferenceException in FindCommitBranchWasBranchedFrom #618
Comments
|
A git clone later and I can reproduce the issue with the debugger attached.
All of the 20 If I checkout
Without looking into the code much further I'm not sure if this method should be ignoring branches where there is no |
|
@nulltoken what do you think? |
|
It turns out |
@JakeGinnivan My guess is that the remote HEAD points to a commit which is unknown from the local repo. Would that make sense? |
|
Hi @nulltoken and @JakeGinnivan, thanks for taking a look. I was pretty sure Which looks like the git graph I'd expected, especially the line here (extracted): I'm happy to help out however I can. |
|
I thought of another test, since GitVersion is running as part of our CI builds from the origin. When I took a new clone from the origin GitVersion is working OK on the I wonder what the difference is between the two clones? |
|
Could you please run |
|
Oh, interesting - thanks this does seem to be where there's a difference: non-working repository working repository |
|
I've been able to reproduce this on another person's repository, different branch, but the same result for |
|
@JakeGinnivan Now that we've got the explanation, any idea regarding how to identify the root cause? How should we guard against this? Skip, explicitly throw? |
|
I recon just skip. It shouldn't affect the running of GitVersion if we skip? |
I don't know any more. It's been too long since I worked on GitVersion to properly remember all the flows. However, adding a commit which skips and log an explicit warning (maybe containing a link to this issue, should maybe help us troubleshoot further the root cause). Not having a remote tracking reference for |
|
Hey @JakeGinnivan and @nulltoken. I think I've got a suggestion that makes sense to me. I think the fact that I've found from researching this particular problem that once your local repo gets in this state it won't be fixed by any other process except cloning again, or manually setting the And GitVersion works again! So my recommendation is:
What do you both think? |
|
That sounds good to me. I think that is safer than filtering out or trying to fix on the fly |
|
👍 as well (although I'm curious about the how this happened in the first place) |
|
Curious - me too. From what I can tell neither of us (who have had this issue) are doing anything very weird, and the continual mentions that "nothing updates the In either case I think we've got a reasonable approach now. I'll get a PR together over the next few days @JakeGinnivan. |
|
Or weeks... :) |
|
Fine by me, I am distracted on a few other things. This way I don't feel as bad :P |
|
I've the same issue using gitversion on AppVeyor only. On my machine it works AppVeyor log [ |
|
@aguacongas Which version of GitVersion are you using? |
|
@asbjornu GitVersion.Portable v4.0.0-beta0001 |
Apologies for the terse Issue, I was out of time today and am hoping to reproduce the issue locally tomorrow.
What I've noticed is this
NullReferenceExceptionstarted after merging frommasterback into ourrelease/3.1.0branch. Now runninggitversion.exefails with the NRE, andGitVersionTaskis doing the same thing in Visual Studio making it horribly slow.Both
GitVersion.PortableandGitVersionTaskare3.1.0.I've worked around this temporarily by adding a Tag to force the SemVer. I haven't found another workaround that gets back to normal operation (without the Tag hack).
Full log file as requested...
The text was updated successfully, but these errors were encountered: