On Thu, 13 Oct 2016 07:15:56 -0400 Tong Sun <suntong...@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. -- 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 email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
