go get: You are not currently on a branch

[Tong Sun]

How to fix the "You are not currently on a branch" error for `go get`?

$ go get -u github.com/mattn/go-sqlite3

# cd .../src/github.com/mattn/go-sqlite3; git pull --ff-only

From https://github.com/mattn/go-sqlite3

 * [new branch]      gh-pages   -> origin/gh-pages

   bbd33c0..38ee283  master     -> origin/master

 * [new branch]      systemlib  -> origin/systemlib

 * [new tag]         v1.0.0     -> v1.0.0

 * [new tag]         v1.1.0     -> v1.1.0

You are not currently on a branch.

Please specify which branch you want to merge with.

See git-pull(1) for details.

    git pull <remote> <branch>

package github.com/mattn/go-sqlite3: exit status 1

[Dave Cheney]

Delete the source from your $GOPATH and run go get again. There are other ways to fix the error but this is a simple solution.

[Matt Silverlock]

Dave's solution is the quick fix, so use that if you need to.

Otherwise: `git status` to figure out what ref you are at. I assume you were working on a branch inside the repo and ended up inside a rebase or otherwise detached HEAD state.

[Tong Sun]

Yep, that works great. Thanks every one!

On Sat, May 28, 2016 at 8:35 PM, Matt Silverlock <elit...@gmail.com> wrote:

Dave's solution is the quick fix, so use that if you need to.

Otherwise: `git status` to figure out what ref you are at. I assume you were working on a branch inside the repo and ended up inside a rebase or otherwise detached HEAD state.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/t9dLLVwsMlM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Modeneis]

Oh this is one of the problems that is really time consuming. I'm not sure if this is related, but I've never had this kind of problems before +1.7.

@Dave, I've tried your "quick-fix" but no luck ...

$ go get google.golang.org/grpc

# cd /opt/gocode/src/golang.org/x/net; git pull --ff-only

You are not currently on a branch. Please specify which

branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

package golang.org/x/net/http2: exit status 1

package golang.org/x/net/trace: cannot find package "golang.org/x/net/trace" in any of:

/usr/local/go/src/golang.org/x/net/trace (from $GOROOT)

/opt/gocode/src/golang.org/x/net/trace (from $GOPATH)

package golang.org/x/net/http2/hpack: cannot find package "golang.org/x/net/http2/hpack" in any of:

/usr/local/go/src/golang.org/x/net/http2/hpack (from $GOROOT)

/opt/gocode/src/golang.org/x/net/http2/hpack (from $GOPATH)

[Thomas Modeneis]

This issue is all over the web, people are having problems multiple times:

http://stackoverflow.com/questions/33064343/go-get-git-error-on-all-sources-but-golang-org

https://github.com/tools/godep/issues/60

https://github.com/golang/go/issues/6042

http://stackoverflow.com/questions/30188499/how-to-do-go-get-on-a-specific-tag-of-a-github-repository

https://github.com/gopherjs/gopherjs/issues/439

https://github.com/grpc/grpc-go/issues/807

https://github.com/kataras/iris/issues/245

Quote from one of the issues, people seem frustrated with Go package management:
"tamird commented on Aug 1

Yes, welcome to Go's terrible package management."

Any ideas ?

Cheers.

On Saturday, May 28, 2016 at 7:42:27 PM UTC+2, Tong Sun wrote:

[andrey mirtchovski]

this is more of a git problem, not a go problem. you're in a 'detached
head' state and don't have a current branch to consider as your base.
the best remediation is to issue 'git checkout master' in the
respective repository. that will provide a correct head to work with.

for more info:

http://stackoverflow.com/questions/5772192/how-can-i-reconcile-detached-head-with-master-origin

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Jan Mercl]

On Wed, Oct 12, 2016 at 2:27 PM Thomas Modeneis <thomas....@gmail.com> wrote:

> Oh this is one of the problems that is really time consuming. I'm not sure if this is related, but I've never had this kind of problems before +1.7.

Not being on a git branch is quite probably not caused by Go (regardless of version).

> @Dave, I've tried your "quick-fix" but no luck ...

> 

> $ go get google.golang.org/grpc
> # cd /opt/gocode/src/golang.org/x/net; git pull --ff-only
> You are not currently on a branch. Please specify which
> branch you want to merge with. See git-pull(1) for details.

Dave's fix was to delete the repo, but the above clearly shows the repo still exists. Maybe you have multiple GOPATHs? Another way how to attempt to fix the problem is to go to the repository directory and trying

        $ git checkout master

HTH

--

-j

[Wojciech S. Czarnecki]

Dnia 2016-10-12, o godz. 02:37:16
Thomas Modeneis <thomas....@gmail.com> napisał(a):

> You are not currently on a branch. Please specify which
> branch you want to merge with. See git-pull(1) for details.

This is common to freshmen to get a checkout of some tag then
forget they did it. This is a root cause of update fails.

> Oh this is one of the problems that is really time consuming. I'm not sure
> if this is related, but I've never had this kind of problems before +1.7.

Do you use any half-baked 'pkg versioning' tool?
If you did not checked by hand, such tool may be a culprit.

> Any ideas ?

Better education?

OK. Go get docs should have a warning box in red flash:

[ Either learn about git usage or never ever tinker within
$GOPATH/src/github.com. If go get -u barks on you with 'You are
not currently on a branch' message, cd into the mentioned directory and do:
'git checkout master' there. After that you may do 'go get -u' again. Rinse
and repeat. ]


--
Wojciech S. Czarnecki
^oo^ OHIR-RIPE

[Thomas Modeneis]

Hi Oir,

The main problem seems to be related to go get believe me or not.
I manage to get this right after I deleted  $GOPATH/pkg/* and  $GOPATH/src/golang.org

Thanks

[Tong Sun]

On Wed, Oct 12, 2016 at 5:56 PM, Thomas Modeneis wrote:

The main problem seems to be related to go get believe me or not.

I kind of agree, in the sense that what we did, was purely "go get", and never tempered with the git underneath. You can blame git, but I think "go get" can do better to avoid the problem in the first place. 

[Jan Mercl]

On Thu, Oct 13, 2016 at 3:59 AM Tong Sun <sunto...@gmail.com> wrote:

> You can blame git, but I think "go get" can do better to avoid the problem in the first place. 

'go get' just executes `git clone` or `git pull`. What would you suggest 'go get' can do to "do better"?

--

-j

[Thomas Modeneis]

> What would you suggest 'go get' can do to "do better"?

I hate comparing Go with Node, but  (I'm sorry)... How about doing the same that NPM does ? NPM installs the target module + target version. End.

[Jan Mercl]

On Thu, Oct 13, 2016 at 8:18 AM Thomas Modeneis <thomas....@gmail.com> wrote:

> I hate comparing Go with Node, but (I'm sorry)... How about doing the same that NPM does ? NPM installs the target module + target version. End.

I'm not familiar with Node. Does "NPM installs the target module" mean it's pulling and/or updating its sources to a VCS?

--

-j

[Tong Sun]

On Thu, Oct 13, 2016 at 1:31 AM, Jan Mercl  wrote:

On Thu, Oct 13, 2016 at 3:59 AM Tong Sun wrote:

> You can blame git, but I think "go get" can do better to avoid the problem in the first place. 

'go get' just executes `git clone` or `git pull`. What would you suggest 'go get' can do to "do better"?

The problem occurs between two consequent 'go get' that may have a long time span. If 

   git checkout master

is suppose to fix the problem, then 'go get' should at least try to do that, I suppose. 

[Jan Mercl]

On Thu, Oct 13, 2016 at 1:15 PM Tong Sun <sunto...@gmail.com> wrote:

> The problem occurs between two consequent 'go get' that may have a long time span. If
>
> git checkout master
> 
> is suppose to fix the problem, then 'go get' should at least try to do that, I suppose. 

It fixes the problem provided no changes were made to the tree. But even if there are no changes made to the tree in the detached head state, or it being on a different branch than master, it would be strange if go get just silently changed the current head state/current branch of a repository someone intentionally put in such state. It's reasonable to suppose that someone needs/wants to be on that branch/in that detached head state so human intervention/supervision is justified, IMO.

--

-j

[Konstantin Khomoutov]

On Thu, 13 Oct 2016 07:15:56 -0400
Tong Sun <sunto...@gmail.com> wrote:

> > > You can blame git, but I think "go get" can do better to avoid the
> > problem in the first place.
> >
> > 'go get' just executes `git clone` or `git pull`. What would you
> > suggest 'go get' can do to "do better"?
> >
>
> The problem occurs between two consequent 'go get' that may have a
> long time span. If
>
> git checkout master
>
> is suppose to fix the problem, then 'go get' should at least try to do
> that, I suppose.

No.

The branch named "master" is not somehow special for `git clone`.
After fetching all the data from the origin repository, it asks that
repository about where its HEAD ref points at. If it points to a
branch, a local branch with its name is created -- pointing to the
commit of that branch.

Sure, in 90% (or more) of bare (that is, "central") Git repos found in
the wild, HEAD points at refs/heads/master, and that's why `git clone`
creates a local branch "master" for you pointing to the same commit
"origin/master" point at, but still the name "master" is not at all
special when cloning. When someone told you to do `git checkout master`
it was actually a conscious oversimplification to avoid explaining the
stuff I have just explaining.

Changing the subject of this discussion a bit, I think that embedding
more magic into `go get` is wrong: there are legitimate cases where you
might have a repository fetched via `go get` in a special state (say,
you have implemented a local fix not yet upstreamed), and you're
supposed to track these things yourself -- tools can't really guess
what you _meant_ when you were working in that repository doing things
which put it into the state it's currently in.

[Thomas Modeneis]

> Does "NPM installs the target module" mean it's pulling and/or updating its sources to a VCS?

NPM decided that releases are part of a module. This module should be release explicitly by the team/developer in charge for the module, and the module version is consequently bumped after.
So developers that just want to use a module, do not have to worry where that project VCS is, if stills online or not, if exists or not. All this factors are mitigated and handled by NPM, due to its release/usage mechanism.

Example: Given a project has version 1.0.0 and the developer executes npm publish, When the module is pushed to NPM, Then your module is released to public usage, And your package.json (file that contains info about the module + version) has the version bumped automatically, And the developer should not be able to release twice under same version.

In the other hand, Go decided (or the absence of a early stage design decision caused this) that releases are linked to explicit commits, so VCS was added to equation to mitigate the problem + enabling people to use external projects into their Go modules... So several projects have been created to address the issue, like godeps, gm, glide. But (correct me if I'm wrong) there is no central repository for releases in Go -> http://stackoverflow.com/questions/38595887/does-golang-have-a-central-repository-for-the-downloaded-third-party-packages

Cheers.   

[Konstantin Khomoutov]

On Thu, 13 Oct 2016 04:36:27 -0700 (PDT)
Thomas Modeneis <thomas....@gmail.com> wrote:

> > Does "NPM installs the target module" mean it's pulling and/or
> > updating
> its sources to a VCS?
>
> NPM decided that releases are part of a module. This module should be
> release explicitly by the team/developer in charge for the module,
> and the module version is consequently bumped after.
> So developers that just want to use a module, do not have to worry
> where that project VCS is, if stills online or not, if exists or not.
> All this factors are mitigated and handled by NPM, due to its
> release/usage mechanism.

That's a strange point you're making here: NPM might not be online just
like the project's repo might be [1].

If we recall the recent left-pad debacle, it becames apparent that if
you really think about the future of your software and wants to make
its lifecycle not depend on the availablilty of external resources, you
have to vendor your dependencies.

So we again arrived at square one [2].

[...]

> In the other hand, Go decided (or the absence of a early stage design
> decision caused this) that releases are linked to explicit commits,
> so VCS was added to equation to mitigate the problem

I think you're wrong on this: you put extra meaning into what `go get`
does. `go get` is merely able to fetch code from several VCS systems
(and knows about the specific of several popular hosting solutions).
It explicitly knows nothing / does not care about which "version" of
the software it manages to download.

You're not at all oblidged to use `go get` (for instance, I, for one,
almost never touch it): instead, you're free to explicitly pick
whatever versions of the 3rd-party libraries you want, and do this in a
way you want it. For instance, I personally use Git subtree merging to
vendor my dependencies, and hence I explicitly decide which versions I
merge (and hence depend on).

> + enabling people to use external projects into their Go modules...
> So several projects have been created to address the issue, like
> godeps, gm, glide. But (correct me if I'm wrong) there is no central
> repository for releases in Go ->
> http://stackoverflow.com/questions/38595887/does-golang-have-a-central-repository-for-the-downloaded-third-party-packages

Yes, there's no central package repository.
Personally, I have no opinion on this.
On the one hand, it might be convenient to have. But that's only if
you're "infected" with an NMP-ish approach to working with packages.
The problem is that proponents of this approach implicitly assume
it's the best thing to have, but this is arguable (i.e. that would be
"one size fits all", and folks at Google explicitly abstrained from
instilling it on the community because they would not use this approach
anyway).

1. https://www.reddit.com/r/rust/comments/35kf6h/now_that_cratesio_is_down/
2. https://golang.org/doc/faq#get_version

[Tristan Colgate]

Do you happen to use godep? I think I've had it cause this problem before. 

[Wojciech S. Czarnecki]

Dnia 2016-10-12, o godz. 23:18:24
Thomas Modeneis <thomas....@gmail.com> napisał(a):

> I hate comparing Go with Node, but (I'm sorry)... How about doing the same
> that NPM does ? NPM installs the target module + target version. End.

And npm is happy to pull in multiple versions of the same library for
the same application. Hobbyists need not to even know that. Real developers
though end filling diligently their peerDependencies just to get notfied.

https://github.com/npm/npm/issues/11294

This is exact scenario Go environment is free off. Hobbyists should live
with most recent api. Devs who prefer to do their work when its due will do
too. Others may elect to vendor all their dependencies. YMMV.

A side effect of Go approach is almost perfect stability of libraries' api.
Once they are past 'experimental' stage authors keep their promises.
Npm ecosystem encourages exact opposite: library author is free to change
api even daily, because 'npm does take care of versioning'. So either one
traces all deps manually, or one has no idea what 'his' app really consist
of. "May it have 39 versions of a single lib? Yes! npm will take care of it."

[Tong Sun]

On Thu, Oct 13, 2016 at 7:35 AM, Konstantin Khomoutov wrote:

Sure, in 90% (or more) of bare (that is, "central") Git repos found in
the wild, HEAD points at refs/heads/master, and that's why `git clone`
creates a local branch "master" for you pointing to the same commit
"origin/master" point at, but still the name "master" is not at all
special when cloning.  When someone told you to do `git checkout master`
it was actually a conscious oversimplification to avoid explaining the
stuff I have just explaining.

Then the problem should at least be made aware of to the lib authors / go developers -- it is the go-sqlite3 that was causing me problems. I.e., it surprised me that even such popular module's author doesn't know the "catch", and switched Git HEAD randomly. 

 

Changing the subject of this discussion a bit, I think that embedding

more magic into `go get` is wrong...

OK. I can buy that. 

[gurp...@gmail.com]

 cd $GOPATH/src/github.com/mattn/go-sqlite3; git pull --ff-only origin master

Add `origin master` suffix to the command suggested by the error. (master or otherwise)

The error occurs because the repo got a new branch since your last go get.

[Thomas Modeneis]

gurp...@gmail.com wrote:
"The error occurs because the repo got a new branch since your last go get." 

...right ... but look how many errors, one have to manually get "fixed" in order get a dependency updated.

$ go get -u github.com/dancannon/gorethink

# cd /opt/gocode/src/github.com/Sirupsen/logrus; git pull --ff-only

From https://github.com/Sirupsen/logrus

   08a8a7c..3ec0642  master     -> origin/master

You are not currently on a branch. Please specify which

branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

package github.com/Sirupsen/logrus: exit status 1

# cd /opt/gocode/src/github.com/cenk/backoff; git pull --ff-only

From https://github.com/cenk/backoff

   cdf48bb..b02f2bb  master     -> origin/master

You are not currently on a branch. Please specify which

branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

package github.com/cenk/backoff: exit status 1

# cd /opt/gocode/src/github.com/hailocab/go-hostpool; git pull --ff-only

You are not currently on a branch. Please specify which

branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

package github.com/hailocab/go-hostpool: exit status 1

# cd /opt/gocode/src/gopkg.in/dancannon/gorethink.v2; git pull --ff-only

From https://gopkg.in/dancannon/gorethink.v2

   e75f34b..016a1d3  master     -> origin/master

   b2c14ad..016a1d3  develop    -> origin/develop

 * [new tag]         v2.2.2     -> v2.2.2

From https://gopkg.in/dancannon/gorethink.v2

 * [new tag]         v2.2.1     -> v2.2.1

You are not currently on a branch. Please specify which

branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

package gopkg.in/dancannon/gorethink.v2/encoding: exit status 1

# cd /opt/gocode/src/gopkg.in/fatih/pool.v2; git pull --ff-only

You are not currently on a branch. Please specify which

branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

package gopkg.in/fatih/pool.v2: exit status 1

[radheshy...@sofocle.com]

Thanks, your solution worked.