Re: How to specify remote branch correctly
On 2012-12-17, Tomas Carnecky wrote: > On Mon, 17 Dec 2012 07:02:46 +, Woody Wu wrote: >> On 2012-12-17, Tomas Carnecky 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.1350d3f9d 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.ytracked linux-3.2.ytracked linux-3.3.ytracked linux-3.4.ytracked linux-3.5.ytracked linux-3.6.ytracked linux-3.7.ynew (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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On Mon, 17 Dec 2012 07:02:46 +, Woody Wu wrote:
> On 2012-12-17, Tomas Carnecky 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}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On 2012-12-17, Tomas Carnecky wrote: > On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill > wrote: >> On 17 December 2012 16:06, Woody Wu 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On 2012-12-17, Andrew Ardill wrote: > On 17 December 2012 16:06, Woody Wu 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On Sun, Dec 16, 2012 at 11:52 PM, Andrew Ardill 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On 17 December 2012 16:30, Tomas Carnecky 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill wrote: > On 17 December 2012 16:06, Woody Wu 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On 17 December 2012 16:06, Woody Wu 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On 2012-12-17, Andrew Ardill wrote: > On 17 December 2012 13:30, Woody Wu 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On 17 December 2012 13:30, Woody Wu 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to specify remote branch correctly
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
