status empty after change in Gopkg

[flibustenet]

First i create Gopkg.tom with

[[constraint]]
branch="master
name="github.com/lib/pq"

Then i change to get a revision

[[constraint]]
revision="9e98792c612dba7c46214aef08ddc93ff358f924"
name="github.com/lib/pq"

(this revision is just one before master)

Now dep status is empty. It should say that i need to upgrade isn't it ?

After dep ensure, dep status show the current revision.

PROJECT            CONSTRAINT  VERSION  REVISION  LATEST  PKGS USED
github.com/lib/pq  *                    9e98792           2 

I would like to see that the lastest is 2704adc878c21e1329f46f6e56a1c387d788ff94

When i put branch="master" dep status is also empty

Hope it'll help

[darkowlzz]

@flibustenet thanks for reporting.

I think the cause of empty status is same as in #161 and we have a fix for it in #611, which would be landing soon.

Empty LATEST appears to be a bug that we need to fix.

[darkowlzz]

Just to confirm, the empty status issue, I tried reproducing it with #611 and status informs what happened and how to fix it.

$ dep status
Lock inputs-digest mismatch. This happens when Gopkg.toml is modified.
Run `dep ensure` to regenerate the inputs-digest.

So we have a fix for it :)

[darkowlzz]

Regarding the empty LATEST in status after running ensure, it seems to be designed to work that way status.go#L331.

// Only if we have a non-rev and non-plain version do/can we display
// anything wrt the version's updateability.

Not sure why or what's stopping us from fetching the latest rev when we have rev version.
@sdboyer correct me?

[darkowlzz]

Not sure why or what's stopping us from fetching the latest rev when we have rev version.

@sdboyer err... ^ 🙄 ?

[sdboyer]

Ahh, I added the extra "fixes", but that is an open question.

[sdboyer]

So the problem with "latest" is that it necessarily assumes some kind of nonbranching forward path from the point we're currently at. Some systems - e.g. svn - always have a linear ordering of revisions, so they can provide this. git, bzr, and hg do not - given only a revision, there could be any number of reachable tip commits from it, because they all construct history as a graph.

semver and branch constraints indicate to the system how the user wants to think of what "latest" means - with semver, it's through the ordering of version numbers; with branches, it's through whatever system the underlying vcs has for constructing a branch history.

[sdboyer]

gonna re-close this though, we can deal with it as part of #663 (or another issue)