dep init fails if GOPATH has a checked out branch not present in remote

[groob]

Today, I tried to run dep init on a new repo https://github.com/groob/autopkgd which resulted in the following errors:

ouchie, solve error: No versions of github.com/groob/plist met constraints:
           empty_data: Unable to update checked out version: fatal: reference is not a tree: 94c3023a0ab2ab1ae7ca10cf1b1416d00c0b77a0

           master: Could not introduce github.com/groob/plist@master, as it is not allowed by constraint empty_data from project github.com/groob/autopkgd.No versions of github.com/groob/plist met constraints:
           empty_data: Unable to update checked out version: fatal: reference is not a tree: 94c3023a0ab2ab1ae7ca10cf1b1416d00c0b77a0

           master: Could not introduce github.com/groob/plist@master, as it is not allowed by constraint empty_data from project github.com/groob/autopkgd.

turns out, $GOPATH/src/github.com/groob/plist had a branch other than master checked out and the changes in that branch were not pushed to github.

git checkout master on the plist repo, and then running dep init again worked.

This issue sounds similar to #158 but I wasn't sure so I'm filing a new issue.

[sdboyer]

Yeah, thanks for reporting this one. I think this issue is actually the tip of a potentially large iceberg. For every version (branch or tag) we pull from GOPATH, we should ideally:

1. Verify that the named ref exists in the upstream source; if it doesn't, solve failure is guaranteed
2. For tags, verify that (if it makes sense for the vcs type), the revision is as expected - e.g., the revision behind tag v1.0.0 is the same as the revision upstream. The solver won't blow up on this case, but it seems probably better to avoid knowingly creating it in the first place if we can, especially given that we haven't sorted out solve warnings yet: Systematic support for "warnings" sdboyer/gps#77
3. For anything with a revision, make sure that revision actually exists upstream. This is probably the most common case - unpushed commits.

[paddie]

Ran into this one today as well. The issue was an un-pushed commit, but wasn't really clear from the error message.

[sdboyer]

I do want to improve the error here, for sure - there's no reason anyone would realize that that's the problem.

But it's a little arduous to figure out if a commit/ref is unpushed (and across different VCSes!) up front. It might be more productive to do some sniffing on failure to see if the error looks like a local-only data issue.

[sdboyer]

@paddie @groob if either of you still happen to have a case handy for this and wouldn't mind testing with the latest dep to see if there's an improvement, I'd find it to be a great help 😄 I think what'll happen silent success, where the rev from on disk ends up being ignored and the "default" version - latest semver tag if there is one, else default branch) gets selected.

[sdboyer]

We've now got a passable answer for this in the FAQ, so closing this out. Thanks!