* How to specify remote branch correctly
@ 2012-12-17 2:30 Woody Wu
2012-12-17 4:27 ` Andrew Ardill
0 siblings, 1 reply; 11+ messages in thread
From: Woody Wu @ 2012-12-17 2:30 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to specify remote branch correctly
2012-12-17 2:30 How to specify remote branch correctly Woody Wu
@ 2012-12-17 4:27 ` Andrew Ardill
2012-12-17 5:06 ` Woody Wu
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Ardill @ 2012-12-17 4:27 UTC (permalink / raw)
To: Woody Wu; +Cc: git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to specify remote branch correctly
2012-12-17 4:27 ` Andrew Ardill
@ 2012-12-17 5:06 ` Woody Wu
2012-12-17 5:13 ` Andrew Ardill
0 siblings, 1 reply; 11+ messages in thread
From: Woody Wu @ 2012-12-17 5:06 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: How to specify remote branch correctly
2012-12-17 5:06 ` Woody Wu
@ 2012-12-17 5:13 ` Andrew Ardill
2012-12-17 5:30 ` Tomas Carnecky
2012-12-17 6:48 ` Woody Wu
0 siblings, 2 replies; 11+ messages in thread
From: Andrew Ardill @ 2012-12-17 5:13 UTC (permalink / raw)
To: Woody Wu; +Cc: git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to specify remote branch correctly
2012-12-17 5:13 ` Andrew Ardill
@ 2012-12-17 5:30 ` Tomas Carnecky
2012-12-17 5:52 ` Andrew Ardill
2012-12-17 7:02 ` Woody Wu
2012-12-17 6:48 ` Woody Wu
1 sibling, 2 replies; 11+ messages in thread
From: Tomas Carnecky @ 2012-12-17 5:30 UTC (permalink / raw)
To: Andrew Ardill, Woody Wu; +Cc: git@vger.kernel.org
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to specify remote branch correctly
2012-12-17 5:30 ` Tomas Carnecky
@ 2012-12-17 5:52 ` Andrew Ardill
2012-12-17 6:44 ` Chris Rorvick
2012-12-17 7:02 ` Woody Wu
1 sibling, 1 reply; 11+ messages in thread
From: Andrew Ardill @ 2012-12-17 5:52 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Woody Wu, git@vger.kernel.org
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to specify remote branch correctly
2012-12-17 5:30 ` Tomas Carnecky
2012-12-17 5:52 ` Andrew Ardill
@ 2012-12-17 7:02 ` Woody Wu
2012-12-17 7:21 ` Tomas Carnecky
1 sibling, 1 reply; 11+ messages in thread
From: Woody Wu @ 2012-12-17 7:02 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to specify remote branch correctly
2012-12-17 7:02 ` Woody Wu
@ 2012-12-17 7:21 ` Tomas Carnecky
2012-12-17 7:41 ` Woody Wu
0 siblings, 1 reply; 11+ messages in thread
From: Tomas Carnecky @ 2012-12-17 7:21 UTC (permalink / raw)
To: Woody Wu, git
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}
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: How to specify remote branch correctly
2012-12-17 7:21 ` Tomas Carnecky
@ 2012-12-17 7:41 ` Woody Wu
0 siblings, 0 replies; 11+ messages in thread
From: Woody Wu @ 2012-12-17 7:41 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to specify remote branch correctly
2012-12-17 5:13 ` Andrew Ardill
2012-12-17 5:30 ` Tomas Carnecky
@ 2012-12-17 6:48 ` Woody Wu
1 sibling, 0 replies; 11+ messages in thread
From: Woody Wu @ 2012-12-17 6:48 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-12-17 7:42 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-17 2:30 How to specify remote branch correctly Woody Wu
2012-12-17 4:27 ` Andrew Ardill
2012-12-17 5:06 ` Woody Wu
2012-12-17 5:13 ` Andrew Ardill
2012-12-17 5:30 ` Tomas Carnecky
2012-12-17 5:52 ` Andrew Ardill
2012-12-17 6:44 ` Chris Rorvick
2012-12-17 7:02 ` Woody Wu
2012-12-17 7:21 ` Tomas Carnecky
2012-12-17 7:41 ` Woody Wu
2012-12-17 6:48 ` Woody Wu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.