Append +0 to first dirty version after tag

[leonardehrenfried]

I wanted to fix #53 but you asked for #52 to be fixed first, so this adds a +0 for dirty snapshots directly after a tag.

In the original bug ticket you say that you also want to add +0000 but I'm confused by this. There was also the suggestion about adding the commit SHA, too.

Can you elaborate what should be there?

Fixes #52.

[raboof]

Thanks for taking the time to look into this!

So with this change a dirty repository on a tag has a version like 1.0.0+0-20140707-1030, and after a couple of commits it would be something like 1.0.0+3-1234abcd-20140707-1030. It might be nice to make those 2 even more consistent by including the headSha in both cases, so the dirty repository on the tag would be like 1.0.0+0-abab2323-20140707-1030.

What do you think?

[dwijnand]

I think @xerial's suggestion (#53 (comment)) is even better than my original one:

Instead of using 0000000 (+0 commit), we should use the actual revision like:

1.0.0+0-xxxxxxx-20140707-1030

This is more informative to tell which git revision is used.

To that end I think all that is needed is dropping the isEmpty from GitCommitSuffixOps's mkString.

[leonardehrenfried]

I'm happy implementing this but I'm wondering: Aren't you two (@raboof, @dwijnand) suggesting the same thing?

[raboof]

I think we're in violent agreement here, yes ;)

[dwijnand]

Yep! Arnout's comment hadn't loaded in my tab by the time I got round to leaving my comment.

[leonardehrenfried]

I took a first stab at implementing this. The problem is that the output of git describe doesn't contain the SHA1 information. Should I get it from a second call to git?

[laughedelic]

@leonardehrenfried probably you need to use --long option?

$ git describe
v2.0.2
$ git describe --long
v2.0.2-0-gd0b6f72

[leonardehrenfried]

I didn't know about --long but it looks exactly like what we need. We can use that output as is without any magic checking it seems. I'll try it out. Am 19.02.2018 10:17 nachm. schrieb "Alexey Alekhin" < [email protected]>:

…

@leonardehrenfried <https://github.com/leonardehrenfried> probably you need to use --long option? $ git describe v2.0.2 $ git describe --long v2.0.2-0-gd0b6f72 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJPMiI2hbQheJTAdxzJ4MUcnZqBrl1yks5tWeTxgaJpZM4SJYSo> .

[laughedelic]

Take into account that it has an extra letter g before the commit SHA and abbreviation is 7 letters by default. I don't know if you can remove g, but you can add --abbrev=8 if you need.

[dwijnand]

We use --abbrev=8 and manage the extra g already: https://github.com/dwijnand/sbt-dynver/blob/v2.1.0/src/main/scala/sbtdynver/DynVerPlugin.scala#L125-L127

Good find on --long!

[leonardehrenfried]

I think this is good for another round of reviews.

I removed the isEmpty check completely and moved all the if statements into GitDescribeOutput instead.

[leonardehrenfried]

Hmm, my plan to make this more elegant failed as it broke a scripted test. I revert that change.

[leonardehrenfried]

But I still think this ready to merge.

[laughedelic]

@leonardehrenfried could you also update the readme?

[dwijnand]

Thanks @leonardehrenfried. I'll try to get to this tomorrow.

[dwijnand]

LGTM! Thank you @leonardehrenfried, as well as @raboof and @laughedelic.