git-update-git-for-windows: strip 'v' from fork tag

[derrickstolee]

When checking for a Git version from a fork such as microsoft/git, we
need to extract the tag name from a JSON object that we get from a REST
API. This differs from the git-for-windows/git mechanism of using the
gitforwindows.org/latest-tag.txt file. In the case of the latest-tag.txt
file, the letter 'v' is stripped from the tag name, allowing comparison
to the installed Git version, which does not include the 'v'.

The 'v' was not previously stripped from the tag name from the fork.
Rectify that, allowing comparisons that present an upgrade.

---

What confuses me about this change is that I don't understand how this ever worked.

To test, I inserted this change into my installed script:

@@ -253,6 +253,7 @@ update_git_for_windows () {
                # We are not testing and we don't have exact equality,
                # so do a careful comparison and look to see if the
                # latest release is strictly newer than ours.
+               echo "Comparing $version to $latest"
                if test 0 -lt "$(version_compare "$version" "$latest")"
                then
                        return

And I saw that $latest included a v while $version did not. This causes the first iteration of version_compare to think there is no number in the $b1 position, so it quits without presenting a new version.

[dscho]

We could make it even safer by scraping off that v in a separate latest="${latest#v}". That way, we don't _expect_ a leading v` but if it's there, we remove it?

[dscho]

An even better place for the statement than I would have used! Thank you so much.

[PhilipOakley]

Aside: Also is there a potential confusion between the dash-rc and dot.rc tag and version strings?

I had noticed that my previous rc2 version didn't auto-update, even if I ran the new update command, so I ended up by updating manually. I didn't manage to replicate the problem (only spend a few minutes on the re-installs to try it), but while looking at the code and the strings did notice the dot/dash difference.

It's also not clear how the rc candidates should be sorted anyway, depending on whether the user already has an rc candidate installed and/or a minor release appears. (Users opt in to rc candidates, but otherwise they by-pass them)

[derrickstolee]

@PhilipOakley some of the -rc handling was done in #358. It does not expect a .rc, though.