How to specify remote branch correctly

How to specify remote branch correctly

[Woody Wu]

Hi, List

I have two branches in the remote, say, origin/master, origin/foo.  Then
when I tried to switch to the remote foo branch, the following two
methods gave me different results:

1. git checkout foo
2. git checkout origin/foo

The first method run silently with success, but the second method
complains that I got a 'detached HEAD'.  So, I think I don't understand
the difference between 'foo' and 'origin/foo'.  Can someone give me a
hint?

Supposing I have another remote defined in .git/config that points
to another repository but also have a same name branch, say
'remote-x/foo', how do I tell git which 'foo' I want to switch to?

The similar problem also exists for 'fetch' command to me.  From the man
page, I don't find answer of how to specify which remote I am going to
fetch from. Can you help me?

Thanks in advance.


-- 
woody
I can't go back to yesterday - because I was a different person then.

Re: How to specify remote branch correctly

[Andrew Ardill]

On 17 December 2012 13:30, Woody Wu <narkewoody@gmail.com> wrote:
> 1. git checkout foo
> 2. git checkout origin/foo
>
> The first method run silently with success, but the second method
> complains that I got a 'detached HEAD'.  So, I think I don't understand
> the difference between 'foo' and 'origin/foo'.  Can someone give me a
> hint?

Hi Woody,

I think you are just missing a couple of important distinctions that
git makes about the different references that exist in your
repository.

A remote reference (origin/foo) describes exactly the state of
somebody else's branch at the time you last synchronised with them. It
does not make sense for you to be able to 'edit' this state, as it
doesn't belong to you. Instead, we create a copy of that reference and
give it a name (git checkout foo origin/foo) and call this a local
reference (foo). Git then provides machinery around keeping these in
sync with each other (git branch --set-upstream foo origin/foo) but we
don't _have_ to keep these in sync at all! In fact, the names can be
completely arbitrary and we don't have to track the upstream at all.

If I have some other remote (remote-x) that has the same branch as
origin but with some other changes I want to look at, we can just
check that out to another branch (git checkout remote-x-foo
remote-x/foo), or simply download it as a remote ref and merge the
changes on top of my existing local branch (git fetch remote-x; git
checkout foo; git merge remote-x/foo).

There are lots of patterns that can emerge from this functionality,
but the main thing to remember is that to create changes on top of a
remote branch, we first need to create a local copy of it. A 'detached
HEAD' here means that we are looking at the remote repository's branch
but don't have a local copy of it, so any changes we make might be
'lost' (that is, not have an easy to find branch name).

Regards,

Andrew Ardill

Re: How to specify remote branch correctly

[Woody Wu]

On 2012-12-17, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> On 17 December 2012 13:30, Woody Wu <narkewoody@gmail.com> wrote:
>> 1. git checkout foo
>> 2. git checkout origin/foo
>>
>> The first method run silently with success, but the second method
>> complains that I got a 'detached HEAD'.  So, I think I don't understand
>> the difference between 'foo' and 'origin/foo'.  Can someone give me a
>> hint?
>
> Hi Woody,
>
> I think you are just missing a couple of important distinctions that
> git makes about the different references that exist in your
> repository.
>
> A remote reference (origin/foo) describes exactly the state of
> somebody else's branch at the time you last synchronised with them. It
> does not make sense for you to be able to 'edit' this state, as it
> doesn't belong to you. Instead, we create a copy of that reference and
> give it a name (git checkout foo origin/foo) and call this a local
> reference (foo). Git then provides machinery around keeping these in
> sync with each other (git branch --set-upstream foo origin/foo) but we
> don't _have_ to keep these in sync at all! In fact, the names can be
> completely arbitrary and we don't have to track the upstream at all.
>
> If I have some other remote (remote-x) that has the same branch as
> origin but with some other changes I want to look at, we can just
> check that out to another branch (git checkout remote-x-foo
> remote-x/foo), or simply download it as a remote ref and merge the
> changes on top of my existing local branch (git fetch remote-x; git
> checkout foo; git merge remote-x/foo).

Thanks for explaining the concept of branch to me.  Now I understood the
difference between local and remote branch.  But I still have
difficulties in answering my own questions.

1. git checkout foo.
By this command, I think I am checking out files in my local branch
named foo, and after that I also switch to the branch. Right?

2. git checkout origin/foo
By this command, I am checking out files in remote branch origin/foo,
but don't create a local branch, so I am not in any branch now. This is
the reason why git tell me that I am in a 'detached HEAD'. Is this
understanding right?

>
> There are lots of patterns that can emerge from this functionality,
> but the main thing to remember is that to create changes on top of a
> remote branch, we first need to create a local copy of it. A 'detached
> HEAD' here means that we are looking at the remote repository's branch
> but don't have a local copy of it, so any changes we make might be
> 'lost' (that is, not have an easy to find branch name).
>

I think here is a little confuse to me.  You mean that a 'detached HEAD'
means I don't have a local copy, but I remember that if I run something
like:
    $ git checkout a-tag-name
then I ususally went into 'detached HEAD' but my local files really get
switched to those files in the tag 'a-tag-name'.  So what does you mean
by 'don't have a local copy'?

Many thanks!


-- 
woody
I can't go back to yesterday - because I was a different person then.

Re: How to specify remote branch correctly

[Andrew Ardill]

On 17 December 2012 16:06, Woody Wu <narkewoody@gmail.com> wrote:
> 1. git checkout foo.
> By this command, I think I am checking out files in my local branch
> named foo, and after that I also switch to the branch. Right?

Correct. Your working directory (files) switch over to whatever your
local branch 'foo' points to, and your HEAD is updated to point to
your local branch 'foo'. Unless something goes wrong/you have
conflicting files/uncommitted changes etc.

> 2. git checkout origin/foo
> By this command, I am checking out files in remote branch origin/foo,
> but don't create a local branch, so I am not in any branch now. This is
> the reason why git tell me that I am in a 'detached HEAD'. Is this
> understanding right?

Correct! Your working directory is updated, however it doesn't make
sense for you to make changes to a remote branch, so HEAD is updated
to be detached.

>>
>> There are lots of patterns that can emerge from this functionality,
>> but the main thing to remember is that to create changes on top of a
>> remote branch, we first need to create a local copy of it. A 'detached
>> HEAD' here means that we are looking at the remote repository's branch
>> but don't have a local copy of it, so any changes we make might be
>> 'lost' (that is, not have an easy to find branch name).
>>
>
> I think here is a little confuse to me.  You mean that a 'detached HEAD'
> means I don't have a local copy, but I remember that if I run something
> like:
>     $ git checkout a-tag-name
> then I ususally went into 'detached HEAD' but my local files really get
> switched to those files in the tag 'a-tag-name'.  So what does you mean
> by 'don't have a local copy'?

I should have been more clear. Here I mean that you don't have a local
copy of the branch reference. Your working directory is updated to be
in sync with the remote branch, but you haven't yet copied that remote
reference to a local branch that you can update with your changes.

Hope that clears it up.

Regards,

Andrew Ardill

Re: How to specify remote branch correctly

[Tomas Carnecky]

On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> On 17 December 2012 16:06, Woody Wu <narkewoody@gmail.com> wrote:
> > 1. git checkout foo.
> > By this command, I think I am checking out files in my local branch
> > named foo, and after that I also switch to the branch. Right?
> 
> Correct. Your working directory (files) switch over to whatever your
> local branch 'foo' points to, and your HEAD is updated to point to
> your local branch 'foo'. Unless something goes wrong/you have
> conflicting files/uncommitted changes etc.

'git checkout foo' has special meaning if a local branch with that name
doesn't exist but there is a remote branch with that name. In that case it's
equivalent to: git checkout -t -b foo origin/foo. Because that's what people
usually want.

Re: How to specify remote branch correctly

[Andrew Ardill]

On 17 December 2012 16:30, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> 'git checkout foo' has special meaning if a local branch with that name
> doesn't exist but there is a remote branch with that name. In that case it's
> equivalent to: git checkout -t -b foo origin/foo. Because that's what people
> usually want.

This is true, but I don't think it is documented. Does anyone know if
this is documented anywhere in particular? The git checkout man pages
seem to not mention it, and the git branch page doesn't seem to
mention it either, but perhaps I am just missing it?

In any case, might be useful to make this behaviour more clear.

Regards,

Andrew Ardill

Re: How to specify remote branch correctly

[Chris Rorvick]

On Sun, Dec 16, 2012 at 11:52 PM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> This is true, but I don't think it is documented.

I noticed this, too.  I was just about to send a patch to add this.

Chris

Re: How to specify remote branch correctly

[Woody Wu]

On 2012-12-17, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> On 17 December 2012 16:06, Woody Wu <narkewoody@gmail.com> wrote:
>> 1. git checkout foo.
>> By this command, I think I am checking out files in my local branch
>> named foo, and after that I also switch to the branch. Right?
>
> Correct. Your working directory (files) switch over to whatever your
> local branch 'foo' points to, and your HEAD is updated to point to
> your local branch 'foo'. Unless something goes wrong/you have
> conflicting files/uncommitted changes etc.
>
>> 2. git checkout origin/foo
>> By this command, I am checking out files in remote branch origin/foo,
>> but don't create a local branch, so I am not in any branch now. This is
>> the reason why git tell me that I am in a 'detached HEAD'. Is this
>> understanding right?
>
> Correct! Your working directory is updated, however it doesn't make
> sense for you to make changes to a remote branch, so HEAD is updated
> to be detached.
>
>>>
>>> There are lots of patterns that can emerge from this functionality,
>>> but the main thing to remember is that to create changes on top of a
>>> remote branch, we first need to create a local copy of it. A 'detached
>>> HEAD' here means that we are looking at the remote repository's branch
>>> but don't have a local copy of it, so any changes we make might be
>>> 'lost' (that is, not have an easy to find branch name).
>>>
>>
>> I think here is a little confuse to me.  You mean that a 'detached HEAD'
>> means I don't have a local copy, but I remember that if I run something
>> like:
>>     $ git checkout a-tag-name
>> then I ususally went into 'detached HEAD' but my local files really get
>> switched to those files in the tag 'a-tag-name'.  So what does you mean
>> by 'don't have a local copy'?
>
> I should have been more clear. Here I mean that you don't have a local
> copy of the branch reference. Your working directory is updated to be
> in sync with the remote branch, but you haven't yet copied that remote
> reference to a local branch that you can update with your changes.
>
> Hope that clears it up.
>

Andre, by this in further exaplaination, I think I fully understood.
Thanks a lot!

-- 
woody
I can't go back to yesterday - because I was a different person then.

Re: How to specify remote branch correctly

[Woody Wu]

On 2012-12-17, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill
> <andrew.ardill@gmail.com> wrote:
>> On 17 December 2012 16:06, Woody Wu <narkewoody@gmail.com> wrote:
>> > 1. git checkout foo.  By this command, I think I am checking out
>> > files in my local branch named foo, and after that I also switch to
>> > the branch. Right?
>> 
>> Correct. Your working directory (files) switch over to whatever your
>> local branch 'foo' points to, and your HEAD is updated to point to
>> your local branch 'foo'. Unless something goes wrong/you have
>> conflicting files/uncommitted changes etc.
>
> 'git checkout foo' has special meaning if a local branch with that
> name doesn't exist but there is a remote branch with that name. In
> that case it's equivalent to: git checkout -t -b foo origin/foo.
> Because that's what people usually want.

I think this is what exactly happened to me in the first time I got the
'foo'.  One new thing to me is the '-t'.  I am not sure wether the '-t'
was used or not in the background.  How do I check the 'upstream'
relationships?  Is there any file under .git recoreded that kind of
information?


-- 
woody
I can't go back to yesterday - because I was a different person then.

Re: How to specify remote branch correctly

[Tomas Carnecky]

On Mon, 17 Dec 2012 07:02:46 +0000, Woody Wu <narkewoody@gmail.com> wrote:
> On 2012-12-17, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> > 'git checkout foo' has special meaning if a local branch with that
> > name doesn't exist but there is a remote branch with that name. In
> > that case it's equivalent to: git checkout -t -b foo origin/foo.
> > Because that's what people usually want.
> 
> I think this is what exactly happened to me in the first time I got the
> 'foo'.  One new thing to me is the '-t'.  I am not sure wether the '-t'
> was used or not in the background.  How do I check the 'upstream'
> relationships?  Is there any file under .git recoreded that kind of
> information?

Yes, that information is recorded in a file somewhere in .git. However, for
most users it's irrelevant which file it is. Git has commands to access this
information. Try one of these:

  git branch -vv
  git remote show origin
  git rev-parse --abbrev-ref --symbolic-full-name @{u}

Re: How to specify remote branch correctly

[Woody Wu]

On 2012-12-17, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> On Mon, 17 Dec 2012 07:02:46 +0000, Woody Wu <narkewoody@gmail.com> wrote:
>> On 2012-12-17, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
>> > 'git checkout foo' has special meaning if a local branch with that
>> > name doesn't exist but there is a remote branch with that name. In
>> > that case it's equivalent to: git checkout -t -b foo origin/foo.
>> > Because that's what people usually want.
>> 
>> I think this is what exactly happened to me in the first time I got the
>> 'foo'.  One new thing to me is the '-t'.  I am not sure wether the '-t'
>> was used or not in the background.  How do I check the 'upstream'
>> relationships?  Is there any file under .git recoreded that kind of
>> information?
>
> Yes, that information is recorded in a file somewhere in .git. However, for
> most users it's irrelevant which file it is. Git has commands to access this
> information. Try one of these:
>
>   git branch -vv

Run this on my local linux tree, I got:
  lgf2410-2.6.16.4         7af1fda - added a ignore rule in .gitignore
  (*~)
  * lgf2410-2.6.34.13        50d3f9d ax88796b verbose debug output
    lgf2410-2.6.34.13-16C554 3ec82e0 more debug on 16C554
      master                   9489e9d [origin/master] Linux 3.7-rc7

Does this mean, I only have local branch master tracked to remote?


>   git remote show origin
Running this I got,

    ...
    linux-3.1.y    tracked
    linux-3.2.y    tracked
    linux-3.3.y    tracked
    linux-3.4.y    tracked
    linux-3.5.y    tracked
    linux-3.6.y    tracked
    linux-3.7.y    new (next fetch will store in remotes/origin)
    master         tracked
  Local branch configured for 'git pull':
    master rebases onto remote master
  Local ref configured for 'git push':
    master pushes to master (local out of date)

I am curious to know how the last 4 lines were printed by git.

  -----
  Local branch configured for 'git pull':
    master rebases onto remote master
  -----

If I have addtional branch other than master that also track to some
remote branch, will it also be listed under this 'git pull' line?

  ----
  Local ref configured for 'git push':
    master pushes to master (local out of date)
  ---

This I totally don't understand, what it mean? I think I did not do a
modification on the local 'master'.

Thanks!

-- 
woody
I can't go back to yesterday - because I was a different person then.