Since we're about to do a v3.0.0 release, let's bump the version to v3.
Make this change automatically with the following command to avoid any
missed items:
git grep -l github.com/git-lfs/git-lfs/v2 | \
xargs sed -i -e 's!github.com/git-lfs/git-lfs/v2!github.com/git-lfs/git-lfs/v3!g'
When our go.mod file was introduced in commit
114e85c2002091eb415040923d872f8e4a4bc636 in PR #3208, the module
path chosen did not include a trailing /v2 component. However,
the Go modules specification now advises that module paths must
have a "major version suffix" which matches the release version.
We therefore add a /v2 suffix to our module path and all its
instances in import paths.
See also https://golang.org/ref/mod#major-version-suffixes for
details regarding the Go module system's major version suffix rule.
We use a sync.Mutex to synchronize access to the string pointer
`gitVersion`, which indicates the version of Git used by the system
running Git LFS.
Our basic usage of the sync.Mutex is not incorrect, but we can improve
the readability by instead using a sync.Once. A sync.Once determines
very quickly (and in an atomic, goroutine-safe fashion) whether or not
_any_ function has been run, and if it hasn't, run it.
By doing this, we can--at the first request--produce a value for the
result of running 'git version', and then return it later to the caller.
This has the following benefits:
- If 'git version' has already been run, we do not need to hold the
lock for the entire duration of the function.
- If 'git version' has not already been run, we only run it once,
retaining the existing behavior.
Only one change, which is the introduction of the `gitVersionErr`
variable. This is a consequence of executing the 'git version' call in a
closure: since we're in a new stack frame, we can't return from our
parent.
Instead, we retain the value for all time, and return _it_, along with
whatever value we got from running 'git version' in the first place.
