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.
Currently, we only need the operating system environment to pass to the
object scanner, but when we start processing SHA-256 repositories, we'll
also need to know about the Git configuration as well to determine the
extensions.objectFormat value (which specifies the hash algorithm).
Let's pass the Git environment, as well as the OS environment, down to
our object scanner.
When running `git lfs status`, we perform a `git diff-index`. However,
we don't update the index first, so any changes, such as permissions
changes due to locking, cause the file to be listed as modified. Since
these changes don't represent actual changes that we're interested in,
refresh the index before running diff-index so that it doesn't produce
spurious output.
We're going to need the environment variables in the object scanner, so
pass the appropriate Environment instance down into the object scanner.
Use an interface to avoid an import loop between the git and config
packages.
Note that the environment is not yet used, but will be in a future
commit.