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.
From: Andrew Ardill <hidden> Date: 2016-06-15 22:55:32
On 17 December 2012 13:30, Woody Wu [off-list ref] 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
On 2012-12-17, Andrew Ardill [off-list ref] wrote:
On 17 December 2012 13:30, Woody Wu [off-list ref] wrote:
quoted
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.
From: Andrew Ardill <hidden> Date: 2016-06-15 22:55:32
On 17 December 2012 16:06, Woody Wu [off-list ref] 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.
quoted
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
From: Tomas Carnecky <hidden> Date: 2016-06-15 22:55:32
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill [off-list ref] wrote:
On 17 December 2012 16:06, Woody Wu [off-list ref] wrote:
quoted
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.
From: Andrew Ardill <hidden> Date: 2016-06-15 22:55:32
On 17 December 2012 16:30, Tomas Carnecky [off-list ref] 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
On 2012-12-17, Andrew Ardill [off-list ref] wrote:
On 17 December 2012 16:06, Woody Wu [off-list ref] wrote:
quoted
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.
quoted
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.
quoted
quoted
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.
On 2012-12-17, Tomas Carnecky [off-list ref] wrote:
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill
[off-list ref] wrote:
quoted
On 17 December 2012 16:06, Woody Wu [off-list ref] wrote:
quoted
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.
From: Tomas Carnecky <hidden> Date: 2016-06-15 22:55:32
On Mon, 17 Dec 2012 07:02:46 +0000, Woody Wu [off-list ref] wrote:
On 2012-12-17, Tomas Carnecky [off-list ref] wrote:
quoted
'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}
On 2012-12-17, Tomas Carnecky [off-list ref] wrote:
On Mon, 17 Dec 2012 07:02:46 +0000, Woody Wu [off-list ref] wrote:
quoted
On 2012-12-17, Tomas Carnecky [off-list ref] wrote:
quoted
'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.