First parent appears to be wrong when commit has multiple parents

[LeonardMeyer]

Hi. We're having a bit of a problem with DynVer (4.0.0) behavior right now. In the doc it is mentioned

Previous version is detected by looking at the closest tag of the parent commit of HEAD.
If the current commit has multiple parents, the first parent will be used. In git, the first parent comes from the branch you merged into (e.g. master in git checkout master && git merge my-feature-branch)

We found that not to be true. Unless the first sentence implies direct parents ? Anyway. We have develop tagged with v1.2.0-SNAPSHOT followed by a couple commits, as well as a master whose HEAD is tagged say v1.2.0 (because we merged a release branch from develop). We then merged master into develop (to retrieve hotfixes). show dynverGitDescribeOutput on develop then shows 1.2.0. From the docs, I expected 1.2.0-SNAPSHOT not 1.2.0, since I basically did "develop in git checkout develop && git merge master".

The problem seems to come from the git describe command in the plugin. Why not just use something like git describe --first-parent ?

[dwijnand]

Hi!

So, first off, that doc is about previous version, that is dynverGitPreviousStableVersion, which isn't the same as dynverGitDescribeOutput.

That said..

Why not just use something like git describe --first-parent ?

Why not indeed? Looking back at the git history, I see no mention of it (even though I'm aware of it myself). Why don't you try make that change, and see if it negatively affects the tests.

[LeonardMeyer]

You mean use --first-parent for dynverGitDescribeOutput? Well, if we're going from the principle that the current dynverGitDescribeOutput behavior is the one you want, it will surely break tests. Or introduce a breaking change behavior wise.

[dwijnand]

the current dynverGitDescribeOutput behavior is the one you want, it will surely break tests. Or introduce a breaking change behavior wise.

Ah, one of my long-standing peeves. Is a change breaking or a "bug-fix"? 😄

The current tests is the behaviour I think is right. The situation that you present also makes sense, so I think it would be a bug-fixing change, rather than a breaking change, provided it doesn't affect the scenarios covered in the tests.

[arkban]

We ran into a similar issue on 4.1.1 :(

We had a homegrown abomination that worked kind of like sbt-dynver a while ago, and we replaced it months ago with sbt-dynver. While working on that original version I found this blog post which was helpful to me (and maybe will be helpful in solving this issue): git-describe and the tale of the wrong commits.