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.


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.

Reply via email to