glide get incorrectly updates glide.lock if --strip-vcs previously used

[mook-as]

It looks like glide get will try to update vendored dependencies (which is reasonable as a solver step), and mistakenly assumes that the vendored repositories have their VCS metadata available (which is not true with --strip-vcs).

Apologies, I thought I saw this filed at some point, but can't seem to find the relevant issue. I looked through everything with the word strip.

Steps to reproduce

(Using the golang:1.6.3 docker container, as a clean baseline)

git init
glide init --non-interactive
glide get --strip-vcs --non-interactive github.com/Masterminds/semver
git add --all
git commit -m 'initial commit'
glide get --strip-vcs --non-interactive github.com/Masterminds/httputil
git diff glide.lock
git log -1

The second-to-last command (git diff glide.lock) has the following output:

diff --git a/glide.lock b/glide.lock
index 89da8bf..a480d57 100644
--- a/glide.lock
+++ b/glide.lock
@@ -1,6 +1,8 @@
-hash: 854e338de9db64a1d1293944bdc6d0b6625ddd959b652dea04436b7df9eab290
-updated: 2016-08-08T22:37:51.437499454Z
+hash: e55c033e6f8e9d8e6dced88d07c32773f7264a7885a25e2ef829e69f85d11559
+updated: 2016-08-08T22:38:14.611306798Z
 imports:
+- name: github.com/Masterminds/httputil
+  version: e9b977e9cf16f9d339573e18f0f1f7ce5d3f419a
 - name: github.com/Masterminds/semver
-  version: 0a6ef7862db61c25926764912dc505ab4f11ebc8
+  version: 1834780c6f38ccac91afbebd4c0e7eef05c47c84
 testImports: []

The version change of semver seems incorrect.
And the last commit of the parent repo (not the vendored semver) is:

root@ab268ef2405a:/go/src/a# git log -1
commit 1834780c6f38ccac91afbebd4c0e7eef05c47c84
Author: Your Name <you@example.com>
Date:   Mon Aug 8 22:38:10 2016 +0000

    initial commit

Note that the version of semver was changed to that of the parent repo. I do not believe it should be changed (since the contents of vendor/github.com/Masterminds/semver/ has not changed).

[mattfarina]

Interesting. Tomorrow I'm going to push a rather large change (as a PR) to the resolution work. The way this part of the code is handled will have changed. I think that will have fixed this.

[shilov]

Just stumbled across this, as well. Looking forward to the fix.

[mook-as]

I can confirm that #547 does appear to fix the issue (at least, running the test case given above no longer reproduces the problem).