{"thread":{"id":"9379","subject":"Terminology question about remote branches.","startedAt":"2007-08-04T10:55:43Z","lastAt":"2007-08-05T16:45:57Z","messageCount":46,"participants":["David Kastrup","Jeff King","Jakub Narebski","Lars Hjemli","Sean","Julian Phillips","Theodore Tso","Junio C Hamano","Steffen Prohaska","Randal L. Schwartz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"49694","messageId":"854pjfin68.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":null,"subject":"Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T10:55:43Z","receivedAt":"2007-08-04T10:55:43Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nI am trying to dig through man-pages and user manual and trying to\nmatch them with reality. I seem to have a hard time. My current\nunderstanding (which definitely differs from the documented state) is\nthat there are two types of branches, local and remote branches, and\nboth types of branches can be remote-tracking (it may not be possible\nto have a non-remote-tracking remote branch, though).\n\nA local branch is one with a local branch head. In contrast, checking\nout a remote branch, while possible, leaves one with a detached head.\n\n\"remote-tracking\" basically means that git-pull will update the branch\naccording to changes in the remote repository.\n\nCreating a branch using git-branch or git-checkout will always create\na local branch which may or may not be remote-tracking according to\nthe --no-track or --track options.\n\nSo there are basically three types of branches in a repository that I\ncan see:\n\nlocal branch, not remote-tracking\nlocal branch, remote-tracking\nremote branch, remote-tracking\n\nThe way to add a remote branch basically is not via git-branch or\ngit-checkout -b (those always create local branches), but by editing\n.git/config.\n\nIs this understanding correct or did I get things completely wrong?\nBecause there is little sense in myself working on changing the\ndocumentation if I have not understood the situation.\n\nAlso, the documentation currently uses \"remote-tracking\"\ninterchangeably for \"local branch, remote-tracking\" and \"remote\nbranch, remote-tracking\", at some times claiming that one can locally\nswitch to a \"remote-tracking\" branch, at other times not.\n\nSo the terminology seems fuzzy at the moment, and my attempt to clear\nit up might not be the preferred way of doing it.\n\nThanks,\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49703","messageId":"20070804120243.GB9716@coredump.intra.peff.net","threadId":"9379","inReplyTo":"854pjfin68.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-04T12:02:43Z","receivedAt":"2007-08-04T12:02:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 04, 2007 at 12:55:43PM +0200, David Kastrup wrote:\n\n> A local branch is one with a local branch head. In contrast, checking\n> out a remote branch, while possible, leaves one with a detached head.\n\nYes, if by \"remote branch\" you mean a \"remote tracking branch\".\n\n> \"remote-tracking\" basically means that git-pull will update the branch\n> according to changes in the remote repository.\n\nA \"remote tracking branch\" is a branch in refs/remotes/* that is updated\nby _git-fetch_ (which is in turn called by git-pull) to track a remote's\nposition of a branch.\n\nA local branch which tracks a remote branch (I don't recall seeing the\nphrase \"remote-tracking\" -- where did this come from?) has the correct\nmagic in .git/config to pull from a specific remote branch when\n'git-pull' is given without arguments.\n\n> Creating a branch using git-branch or git-checkout will always create\n> a local branch which may or may not be remote-tracking according to\n> the --no-track or --track options.\n\nYes, although again, I think calling it a \"remote-tracking branch\" to\nmean \"a local branch that tracks a remote branch\" is confusingly similar\nto the more common \"remote tracking branch\" to mean \"a branch in\nrefs/remotes that track's a remote repository's idea of a branch\".\n\n> So there are basically three types of branches in a repository that I\n> can see:\n> \n> local branch, not remote-tracking\n> local branch, remote-tracking\n> remote branch, remote-tracking\n\nNo, the remote branch is not remote-tracking in the sense that you\ndefined above; it is not meant to be pulled into.\n\nI think you are confused by two uses of the word \"track\". In one case,\nwe mean that git-fetch will remember the remote's idea of a branch in\nrefs/remotes//. In another, we mean that a local branch\nwill default to pulling from a particular (remote,branch) combination.\n\n> So the terminology seems fuzzy at the moment, and my attempt to clear\n> it up might not be the preferred way of doing it.\n\nYes, it is very fuzzy. Using \"track\" for the concept of a local branch\ndefaulting to a particular (remote,branch) pair for git-pull is, I\nthink, more recent and less used. If there were another term for this,\nit might be more clear.\n\n-Peff\n"},{"id":"49706","messageId":"f91qic$n06$1@sea.gmane.org","threadId":"9379","inReplyTo":"854pjfin68.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-04T12:14:04Z","receivedAt":"2007-08-04T12:14:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: David Kastrup , git@vger.kernel.org]\n\nDavid Kastrup wrote:\n\n> The way to add a remote branch basically is not via git-branch or\n> git-checkout -b (those always create local branches), but by editing\n> .git/config.\n\nOr by using \"git remote\" command.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"49710","messageId":"85tzrfh3yg.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070804120243.GB9716@coredump.intra.peff.net","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T12:36:07Z","receivedAt":"2007-08-04T12:36:07Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n> On Sat, Aug 04, 2007 at 12:55:43PM +0200, David Kastrup wrote:\n>\n>> A local branch is one with a local branch head. In contrast, checking\n>> out a remote branch, while possible, leaves one with a detached head.\n>\n> Yes, if by \"remote branch\" you mean a \"remote tracking branch\".\n\nJeff, I actually have no _clue_ what I \"mean\" with respect to the\nestablished git terminology because I can't reconcile the\ndocumentation's use of words with my meagre understanding of the\ntechnical processes involved.\n\nSo I can't even tell you whether \"by remote branch I mean a remote\ntracking branch\".\n\n>> \"remote-tracking\" basically means that git-pull will update the\n>> branch according to changes in the remote repository.\n>\n> A \"remote tracking branch\" is a branch in refs/remotes/* that is\n> updated by _git-fetch_ (which is in turn called by git-pull) to\n> track a remote's position of a branch.\n>\n> A local branch which tracks a remote branch (I don't recall seeing\n> the phrase \"remote-tracking\" -- where did this come from?) has the\n> correct magic in .git/config to pull from a specific remote branch\n> when 'git-pull' is given without arguments.\n>\n>> Creating a branch using git-branch or git-checkout will always\n>> create a local branch which may or may not be remote-tracking\n>> according to the --no-track or --track options.\n>\n> Yes, although again, I think calling it a \"remote-tracking branch\"\n> to mean \"a local branch that tracks a remote branch\" is confusingly\n> similar to the more common \"remote tracking branch\" to mean \"a\n> branch in refs/remotes that track's a remote repository's idea of a\n> branch\".\n\nWell, of _course_ it is confusingly similar. After all, I am posting\nthis question because I _am_ confused! And I am trying to both clear\nup my confusion as well as get an idea how to fix the documentation to\nbe less confusing.\n\n>> So there are basically three types of branches in a repository that\n>> I can see:\n>> \n>> local branch, not remote-tracking local branch, remote-tracking\n>> remote branch, remote-tracking\n>\n> No, the remote branch is not remote-tracking in the sense that you\n> defined above; it is not meant to be pulled into.\n\nSigh. But it is cached and updated locally in some manner when\npulling, isn't it? I can diff against it.\n\n> I think you are confused by two uses of the word \"track\". In one\n> case, we mean that git-fetch will remember the remote's idea of a\n> branch in refs/remotes//. In another, we mean that a\n> local branch will default to pulling from a particular\n> (remote,branch) combination.\n>\n>> So the terminology seems fuzzy at the moment, and my attempt to\n>> clear it up might not be the preferred way of doing it.\n>\n> Yes, it is very fuzzy. Using \"track\" for the concept of a local\n> branch defaulting to a particular (remote,branch) pair for git-pull\n> is, I think, more recent and less used. If there were another term\n> for this, it might be more clear.\n\nIt is not just git-pull. I don't get the fine lines between \"remote\",\n\"remote tracking\" and the respective details in either the user manual\nor the manual pages of branch-related commands.\n\nAnd it's actually worse after your explanations. Previously I\nimagined to have a chance to figure this out on my own, by trying to\nabstract from what I see happening when using the various commands.\n\nNow I think that I basically have no chance figuring this out on my\nown sufficiently well to be able to improve the documentation.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49714","messageId":"8c5c35580708040607ya186edcg89fbc90587b64d68@mail.gmail.com","threadId":"9379","inReplyTo":"85tzrfh3yg.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Lars Hjemli","fromEmail":"lh@elementstorage.no","sentAt":"2007-08-04T13:07:01Z","receivedAt":"2007-08-04T13:07:01Z","isPatch":false,"sender":{"key":"lh@elementstorage.no","avatar":null},"body":"On 8/4/07, David Kastrup wrote:\n> Now I think that I basically have no chance figuring this out on my\n> own sufficiently well to be able to improve the documentation.\n\nRemote-tracking branch:\n A local copy of a branch in another repository. This kind of branch\n cannot be updated by 'git-commit' but only by 'git-fetch' (hence\n indirectly by 'git-pull' and 'git-remote update'). If you try to\n 'git-checkout' a remote-tracking branch, you will get a detached HEAD.\n\nLocal branch:\n A branch to which you may commit changes. Optionally, the branch can be\n configured to \"follow\" one of your remote-tracking branches. This means\n that a 'git-pull' without arguments (when your local branch is checked\n out), will automatically 'git-fetch' and then 'git-merge' the remote-\n tracking branch.\n\nExample:\n\nYour local branch 'master' is setup to \"follow\" 'refs/remotes/origin/master'.\nSo if you do this:\n\n$ git checkout master\n$ git pull\n\nThen the 'git pull'-command will do this:\n\n$ git fetch -f origin master:remotes/origin/master\n$ git merge remotes/origin/master\n\n\nThe magic setup that makes this happen is the following lines in .git/config:\n\n[remote \"origin\"]\n url = git://git.kernel.org/pub/scm/git/git.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\n\nWas this helpful?\n\n-- \nlarsh\n"},{"id":"49717","messageId":"20070804092933.aaec6d52.seanlkml@sympatico.ca","threadId":"9379","inReplyTo":"854pjfin68.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-08-04T13:29:33Z","receivedAt":"2007-08-04T13:29:33Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 04 Aug 2007 12:55:43 +0200\nDavid Kastrup wrote:\n\n> I am trying to dig through man-pages and user manual and trying to\n> match them with reality. I seem to have a hard time. My current\n> understanding (which definitely differs from the documented state) is\n> that there are two types of branches, local and remote branches, and\n> both types of branches can be remote-tracking (it may not be possible\n> to have a non-remote-tracking remote branch, though).\n>\n> A local branch is one with a local branch head. In contrast, checking\n> out a remote branch, while possible, leaves one with a detached head.\n\nYes.\n\n> \"remote-tracking\" basically means that git-pull will update the branch\n> according to changes in the remote repository.\n\nTo be clear, it's the job of git-fetch to update remote-tracking branches\nwith any changes found in the remote repository. Git-pull runs git-fetch\nand then runs a git-merge to update the currently-checked-out branch.\n\nWhen this happens, git-merge must decide which remote-tracking-branch\nto merge into the currently checked out local branch. You can set which\nremote-tracking-branch will be selected in this situation with\nthe --track option.\n\nSo assuming a remote-repo has two branches \"master\" and \"branchX\":\n\n git clone remote-repo\n\nwill give us two remote-branch (AKA remote-tracking-branches) of\n\"origin/master\" and \"origin/branchX\". So:\n\n git branch --track mylocalbranch origin/branchX\n git checkout mylocalbranch\n\nCreates a local branch named \"mylocalbranch\" that by default will\nmerge in any changes found in the remote-tracking branch\n\"origin/branchX\". Thus:\n\n git pull\n\nFirst runs git fetch which will update all remote-tracking branches\nsuch as origin/master and origin/branchX. Then it runs git merge.\nGit merge has to decide whether to merge in the changes from\norigin/master or origin/branchX. Because of the --track option used\nto setup \"mylocalbranch\", \"origin/branchX\" will be merged.\n\n> Creating a branch using git-branch or git-checkout will always create\n> a local branch which may or may not be remote-tracking according to\n> the --no-track or --track options.\n\nNo, a local branch is never a remote-tracking branch; even when created\nwith a --track option. The --track option has muddied the terminology\nwaters a bit and you're not the first to be confused by it. The\n--track selects a branch from the repo to merge by default.\n\n> So there are basically three types of branches in a repository that I\n> can see:\n> \n> local branch, not remote-tracking\n> local branch, remote-tracking\n> remote branch, remote-tracking\n> \n> The way to add a remote branch basically is not via git-branch or\n> git-checkout -b (those always create local branches), but by editing\n> .git/config.\n> \n> Is this understanding correct or did I get things completely wrong?\n> Because there is little sense in myself working on changing the\n> documentation if I have not understood the situation.\n\nFunctionally, your understanding is correct. But it helps when you\nunderstand that remote-branches are the \"real\" remote-tracking-branches.\nYou don't commit to them locally, they are essentially read-only copies\nof exactly what is happening in a remote repository.\n\nA local --track branch, is one that merges changes from the proper\nremote-tracking-branch, and is also a place where you can commit your\nown work.\n\n> Also, the documentation currently uses \"remote-tracking\"\n> interchangeably for \"local branch, remote-tracking\" and \"remote\n> branch, remote-tracking\", at some times claiming that one can locally\n> switch to a \"remote-tracking\" branch, at other times not.\n\nA remote branch and a remote-tracking branch are the same thing.\nStrictly speaking a local branch is never a remote-tracking-branch\nalthough the \"--track\" option makes that harder to explain.\n\n> So the terminology seems fuzzy at the moment, and my attempt to clear\n> it up might not be the preferred way of doing it.\n\nYeah, the documentation could use some fine tuning.\n\nSean\n"},{"id":"49718","messageId":"85k5sbh129.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"8c5c35580708040607ya186edcg89fbc90587b64d68@mail.gmail.com","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T13:38:38Z","receivedAt":"2007-08-04T13:38:38Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Lars Hjemli\" writes:\n\n> On 8/4/07, David Kastrup wrote:\n>> Now I think that I basically have no chance figuring this out on my\n>> own sufficiently well to be able to improve the documentation.\n>\n> Remote-tracking branch:\n> A local copy of a branch in another repository. This kind of branch\n> cannot be updated by 'git-commit' but only by 'git-fetch' (hence\n> indirectly by 'git-pull' and 'git-remote update'). If you try to\n> 'git-checkout' a remote-tracking branch, you will get a detached HEAD.\n>\n> Local branch:\n> A branch to which you may commit changes. Optionally, the branch can be\n> configured to \"follow\" one of your remote-tracking branches. This means\n> that a 'git-pull' without arguments (when your local branch is checked\n> out), will automatically 'git-fetch' and then 'git-merge' the remote-\n> tracking branch.\n\nDoes that mean that specifying \"--track\" to git-checkout or git-branch\nnever creates a remote-tracking branch?\n\n> Example:\n>\n> Your local branch 'master' is setup to \"follow\"\n> 'refs/remotes/origin/master'.\n\nSo --track/--no-track are actually supposed to be --follow and\n--no-follow?\n\n> So if you do this:\n>\n> $ git checkout master\n> $ git pull\n>\n> Then the 'git pull'-command will do this:\n>\n> $ git fetch -f origin master:remotes/origin/master\n\nThis is then tracking?\n\n> $ git merge remotes/origin/master\n\nAnd this is then following?\n\n> The magic setup that makes this happen is the following lines in .git/config:\n>\n> [remote \"origin\"]\nNamely: a remote-tracking branch \"origin\"\n\n> url = git://git.kernel.org/pub/scm/git/git.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n>\n> [branch \"master\"]\n> remote = origin\n\nNamely: follow the remote tracking branch origin?\n\n> merge = refs/heads/master\n>\n>\n> Was this helpful?\n\nSo we have remote tracking branches, and we have local branches\nfollowing remote tracking branches, and \"--track\" and \"--no-track\"\ncreate local branches following or not following a remote tracking\nbranch? And have nothing whatsoever to do with tracking or not\ntracking a remove branch?\n\nTalk about misleading option names here.\n\nThen in man git-branch we have:\n\n\tIn its second form, a new branch named will be\n\tcreated. It will start out with a head equal to the one\n\tgiven as . If no is given, the\n\tbranch will be created with a head equal to that of the\n\tcurrently checked out branch.\n\n\tWhen a local branch is started off a remote branch, git can\n\tsetup the branch so that git-pull(1) will appropriately\n\tmerge from that remote branch. If this behavior is desired,\n\tit is possible to make it the default using the global\n\tbranch.autosetupmerge configuration flag. Otherwise, it can\n\tbe chosen per-branch using the --track and --no-track\n\toptions.\n\nWhat does \"remote branch\" in this context mean? A local branch\nfollowing a remote tracked branch? A remote tracked branch (which by\ndefinition can't be checked out as a branch, since that leads to a\ndetached head)? What does \"start off\" mean in this context? If I\ncan't check out a remote branch, I can't start off on it, can I?\n\nDoes \"--track\" mean that the new branch will copy any \"remote\" lines\nwhich incidentally don't point to remote branches as their name would\nsuggest, but rather to remote tracking branches? And we want to have\nthe relation to the remote tracking branch preserved, not to the\nactual remote branch?\n\nI don't get it. Really. No chance. There are fine distinction lines\nin the git terminology, it would appear, and those lines are freely\nignored in naming options and configuration parameters. And the\nmanual pages themselves are not overly concerned about explaining\nthose distinctions either.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49721","messageId":"85ejijgzzg.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070804092933.aaec6d52.seanlkml@sympatico.ca","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T14:01:55Z","receivedAt":"2007-08-04T14:01:55Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Sean writes:\n\n> David Kastrup wrote:\n>\n>> A local branch is one with a local branch head. In contrast,\n>> checking out a remote branch, while possible, leaves one with a\n>> detached head.\n>\n> Yes.\n>\n>> \"remote-tracking\" basically means that git-pull will update the\n>> branch according to changes in the remote repository.\n>\n> To be clear, it's the job of git-fetch to update remote-tracking\n> branches with any changes found in the remote repository. Git-pull\n> runs git-fetch and then runs a git-merge to update the\n> currently-checked-out branch.\n>\n> When this happens, git-merge must decide which\n> remote-tracking-branch to merge into the currently checked out local\n> branch. You can set which remote-tracking-branch will be selected\n> in this situation with the --track option.\n>\n> So assuming a remote-repo has two branches \"master\" and \"branchX\":\n>\n> git clone remote-repo\n>\n> will give us two remote-branch (AKA remote-tracking-branches) of\n> \"origin/master\" and \"origin/branchX\". So:\n>\n> git branch --track mylocalbranch origin/branchX\n> git checkout mylocalbranch\n\nSo --track does not set up a tracking branch, but makes a local\n_following_ branch _refer_ to a tracking branch.\n\nWhat happens with\n\n git checkout origin/branchX\n git branch --track mylocalbranch\n git checkout mylocalbranch\n\n? What if after the checkout (which leads to a detached head) I check\nin a few things, and then decide to name the branch and set it up as\nfollowing a remote tracking branch? Instead of using git-branch for\nsetting up the following, do I have to explicitly add the respective\n\"remote\" line (which does not specify a remote, but a remote tracking\nbranch) into, uh, where?\n\n> No, a local branch is never a remote-tracking branch; even when\n> created with a --track option. The --track option has muddied the\n> terminology waters a bit and you're not the first to be confused by\n> it. The --track selects a branch from the repo to merge by default.\n\nWell, GOOD. I have already come to the conclusion that the \"--track\"\noption, like the \"remote\" configuration recorded by it have the main\npurpose of confusing people and should not be confused with setting up\na remote tracking branch, or referring to a remote branch.\n\n> A remote branch and a remote-tracking branch are the same thing.\n> Strictly speaking a local branch is never a remote-tracking-branch\n> although the \"--track\" option makes that harder to explain.\n\nYou bet.\n\n>> So the terminology seems fuzzy at the moment, and my attempt to\n>> clear it up might not be the preferred way of doing it.\n>\n> Yeah, the documentation could use some fine tuning.\n\nIt is much too fine-tuned already. I think that first option names\nand config file options need to get some coarse-tuning where one does\nnot have to split hairs and ignore the meaning of terms in order to\nunderstand them.\n\nI have now \"following\" or \"automerge\" local branches which are set up\nto follow a \"remote tracking\" branch. Presumably, if I do\n\ngit-branch -b new-branch --track remote-branch\n\nthen I get a following branch set up which follows/automerges a remote\ntracking branch. So far so good. What do I get with\n\ngit-branch -b another-new-branch --track new-branch\n\nDoes this follow/automerges with new-branch? Does this\nfollow/automerge with remote-branch?\n\nWhat if I do\n\ngit-checkout remote-branch\ngit-branch -b new-branch --track\n\nDoes this follow anything?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49722","messageId":"8c5c35580708040703w44781498t7396588a3f8c81c8@mail.gmail.com","threadId":"9379","inReplyTo":"85k5sbh129.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-08-04T14:03:48Z","receivedAt":"2007-08-04T14:03:48Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 8/4/07, David Kastrup wrote:\n> \"Lars Hjemli\" writes:\n>\n> > On 8/4/07, David Kastrup wrote:\n> >> Now I think that I basically have no chance figuring this out on my\n> >> own sufficiently well to be able to improve the documentation.\n> >\n> > Remote-tracking branch:\n> > A local copy of a branch in another repository. This kind of branch\n> > cannot be updated by 'git-commit' but only by 'git-fetch' (hence\n> > indirectly by 'git-pull' and 'git-remote update'). If you try to\n> > 'git-checkout' a remote-tracking branch, you will get a detached HEAD.\n> >\n> > Local branch:\n> > A branch to which you may commit changes. Optionally, the branch can be\n> > configured to \"follow\" one of your remote-tracking branches. This means\n> > that a 'git-pull' without arguments (when your local branch is checked\n> > out), will automatically 'git-fetch' and then 'git-merge' the remote-\n> > tracking branch.\n>\n> Does that mean that specifying \"--track\" to git-checkout or git-branch\n> never creates a remote-tracking branch?\n\nYes. The \"--track\" option just adds some extra info in .git/config:\n\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\n\nThis info is then used by \"git-pull\" to\n1. fetch updates from the remote repository \"origin\"\n2. merge those updates from refs/remotes/origin/master\n\n>\n> > Example:\n> >\n> > Your local branch 'master' is setup to \"follow\"\n> > 'refs/remotes/origin/master'.\n>\n> So --track/--no-track are actually supposed to be --follow and\n> --no-follow?\n\nMaybe ;-)\n\nI just tried to avoid using the word \"track\" in more than one context,\nsince it seemed to be a main source of confusion.\n\n>\n> > So if you do this:\n> >\n> > $ git checkout master\n> > $ git pull\n> >\n> > Then the 'git pull'-command will do this:\n> >\n> > $ git fetch -f origin master:remotes/origin/master\n>\n> This is then tracking?\n\nYes, this is the part that downloads objects from the remote\nrepository and updates refs/remotes/origin/master to refer to the same\ncommit as the master branch in the remote repository.\n\n>\n> > $ git merge remotes/origin/master\n>\n> And this is then following?\n\nYes, this updates your local 'master' with the commits downloaded by git-fetch\n\n\n>\n> > The magic setup that makes this happen is the following lines in .git/config:\n> >\n> > [remote \"origin\"]\n> Namely: a remote-tracking branch \"origin\"\n\nNo. A remote repository: the name 'origin' can be used as an alias for\n\n git://git.kernel.org/pub/scm/git/git.git\n\n>\n> > url = git://git.kernel.org/pub/scm/git/git.git\n> > fetch = +refs/heads/*:refs/remotes/origin/*\n> >\n> > [branch \"master\"]\n> > remote = origin\n>\n> Namely: follow the remote tracking branch origin?\n\nNo. Fetch objects from the remote repository alias \"origin\"\n\n>\n> > merge = refs/heads/master\n\nAnd this is the info added by \"git branch --track\" which enables the\nautomatic merging of refs/remotes/origin/master (since\nrefs/remotes/origin/master is your local copy of refs/heads/master in\nthe 'origin' repository)\n\n\n> >\n> >\n> > Was this helpful?\n\nTalking to myself: obviously not\n\n\n-- \nlarsh\n"},{"id":"49724","messageId":"854pjfgzit.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"8c5c35580708040703w44781498t7396588a3f8c81c8@mail.gmail.com","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T14:11:54Z","receivedAt":"2007-08-04T14:11:54Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Lars Hjemli\" writes:\n\n>> > Was this helpful?\n>\n> Talking to myself: obviously not\n\nDisagree. \"Does this answer all questions and makes git's behavior\nperfectly transparent\" -- no. But let's not confuse \"magical\" with\n\"helpful\" here.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49728","messageId":"85y7grfkbe.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"854pjfgzit.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T14:25:41Z","receivedAt":"2007-08-04T14:25:41Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Kastrup writes:\n\n> \"Lars Hjemli\" writes:\n>\n>>> > Was this helpful?\n>>\n>> Talking to myself: obviously not\n>\n> Disagree. \"Does this answer all questions and makes git's behavior\n> perfectly transparent\" -- no. But let's not confuse \"magical\" with\n> \"helpful\" here.\n\nOk, let's have another go. Maybe I have understood more as compared\nwith last time.\n\ngit-branch/git-commit -b creates and manages local branches, nothing\nelse. Local branches' defining feature is that they have a branch\nhead I can move around myself.\n\nThen there are non-local branches. Their defining feature is that\nthey have no locally moving branch head and _must_ track a remote\nbranch.\n\nBut local branches _also_ can track the progress/head of a remote\nbranch. Since they have a locally moving branch head, this will often\nlead to merge conflicts which must be resolved.\n\nSo this is more or less what I understand now. There really is no\ndifference between \"tracking\" and \"following\" as I thought previously.\nIt is just that a local branch which happens to track a remote branch\nis basically a remote tracking branch with a head of its own.\n\nWhich means it can get merge conflicts. Can we get merge conflicts\nwith a remote tracking branch, too? Namely when the remote branch\nmessed with its history, rebased/reverted stuff?\n\nSo that the real difference between a local and a remote tracking\nbranch is not that the latter tracks a remote branch (the former can\ndo that as well), but that the latter has no local branch head and\nthat saves us a lot (but not necessary all) merge conflicts?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49730","messageId":"8c5c35580708040735l54d1b9c7i40cd80d7d11e2961@mail.gmail.com","threadId":"9379","inReplyTo":"85y7grfkbe.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-08-04T14:35:09Z","receivedAt":"2007-08-04T14:35:09Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 8/4/07, David Kastrup wrote:\n> Can we get merge conflicts\n> with a remote tracking branch, too? Namely when the remote branch\n> messed with its history, rebased/reverted stuff?\n\nNo, since the \"fetch\" line in .git/config is prefixed by '+', which\ngets translated to the '-f' option for 'git-fetch'.\n\nAnd this was probably the primary reason for refs/remotes/* in the\nfirst place: you have a namespace in which there is no chance for\n'git-fetch' to overwrite local changes (ancient git had no such\nnamespace).\n\n-- \nlarsh\n"},{"id":"49732","messageId":"20070804104851.162d7e00.seanlkml@sympatico.ca","threadId":"9379","inReplyTo":"85ejijgzzg.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-08-04T14:48:51Z","receivedAt":"2007-08-04T14:48:51Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 04 Aug 2007 16:01:55 +0200\nDavid Kastrup wrote:\n\n> So --track does not set up a tracking branch, but makes a local\n> _following_ branch _refer_ to a tracking branch.\n\nSure, that's one way to describe it; perhaps it would be best if\nwe switched to that nomenclature in the documentation.\n\n> What happens with\n> \n> git checkout origin/branchX\n> git branch --track mylocalbranch\n> git checkout mylocalbranch\n\nThis is easy to test, and the answer is that no tracking is set up.\nYou must supply the remote-tracking-branch on the command line with\nthe --track option to git branch. Actually I realized that with a\nnew enough version of Git, --track is implied.\n\n> ? What if after the checkout (which leads to a detached head) I check\n> in a few things, and then decide to name the branch and set it up as\n> following a remote tracking branch? Instead of using git-branch for\n> setting up the following, do I have to explicitly add the respective\n> \"remote\" line (which does not specify a remote, but a remote tracking\n> branch) into, uh, where?\n\nIt's not a problem, you could just add an appropriate [branch...] section\nin your .git/config. Actually looking at a typical branch section\nis even more confusing to me:\n\n $ git branch fudge origin/fix1\n\nadds this to the .git/config:\n\n [branch \"fudge\"]\n remote = origin\n merge = refs/heads/fix1\n\nThe config file does not record the remote-tracking-branch, instead\nit explicitly records the remote repository information. So it sure\nappears that if you add the --track option, it _does_ make the local\nbranch track a remote directly. Thus it's hard to call it anything\nbut what you labelled it, a local tracking-branch.\n\nWhile I thought i had a handle on this, i'm now officially more\nconfused than you; hopefully someone with knowledge of the guts\nof Git will speak up. Junio Help!\n\nSean\n"},{"id":"49733","messageId":"Pine.LNX.4.64.0708041542270.11191@beast.quantumfyre.co.uk","threadId":"9379","inReplyTo":"85y7grfkbe.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-08-04T14:50:21Z","receivedAt":"2007-08-04T14:50:21Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sat, 4 Aug 2007, David Kastrup wrote:\n\n> David Kastrup writes:\n>\n>> \"Lars Hjemli\" writes:\n>>\n>>>>> Was this helpful?\n>>>\n>>> Talking to myself: obviously not\n>>\n>> Disagree. \"Does this answer all questions and makes git's behavior\n>> perfectly transparent\" -- no. But let's not confuse \"magical\" with\n>> \"helpful\" here.\n>\n> Ok, let's have another go. Maybe I have understood more as compared\n> with last time.\n>\n> git-branch/git-commit -b creates and manages local branches, nothing\n> else. Local branches' defining feature is that they have a branch\n> head I can move around myself.\n>\n> Then there are non-local branches. Their defining feature is that\n> they have no locally moving branch head and _must_ track a remote\n> branch.\n>\n> But local branches _also_ can track the progress/head of a remote\n> branch. Since they have a locally moving branch head, this will often\n> lead to merge conflicts which must be resolved.\n>\n> So this is more or less what I understand now. There really is no\n> difference between \"tracking\" and \"following\" as I thought previously.\n> It is just that a local branch which happens to track a remote branch\n> is basically a remote tracking branch with a head of its own.\n>\n> Which means it can get merge conflicts. Can we get merge conflicts\n> with a remote tracking branch, too? Namely when the remote branch\n> messed with its history, rebased/reverted stuff?\n\nWell, sort of - they are not really merge conflicts as there is no merging \ninvolved. Fetching is strictly an updating process, either we update the \nbranch or we don't.\n\nWhen updating a remote tracking branch there are two possible scenarios:\n\n1) the new head is a superset of the old head (i.e. the old head forms \npart of the history of the new)\n2) the new head is not a superset of the old head (i.e. the old head does \nnot form part of the history of the new)\n\nThe normal case is 1), and we simply update the branch to point at the \nnew commit. However what happens in case 2) depends on the configuration. \nIf we have told git to force an update (indicated by the '+' on the \nbeginning of the fetch line in the config) then we simply accept the new \nhead as with case 1), otherwise we complain to the user and don't update \nthat branch\n\n> So that the real difference between a local and a remote tracking\n> branch is not that the latter tracks a remote branch (the former can\n> do that as well), but that the latter has no local branch head and\n> that saves us a lot (but not necessary all) merge conflicts?\n\nYes. A remote tracking branch is basically a read-only local cache of \nsomething that exists in some other repository.\n\n-- \nJulian\n\n ---\nIf you're going to do something tonight that you'll be sorry for tomorrow\nmorning, sleep late.\n \t\t-- Henny Youngman\n"},{"id":"49735","messageId":"85odhnfiau.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"8c5c35580708040735l54d1b9c7i40cd80d7d11e2961@mail.gmail.com","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T15:09:13Z","receivedAt":"2007-08-04T15:09:13Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Lars Hjemli\" writes:\n\n> On 8/4/07, David Kastrup wrote:\n>> Can we get merge conflicts\n>> with a remote tracking branch, too? Namely when the remote branch\n>> messed with its history, rebased/reverted stuff?\n>\n> No, since the \"fetch\" line in .git/config is prefixed by '+', which\n> gets translated to the '-f' option for 'git-fetch'.\n>\n> And this was probably the primary reason for refs/remotes/* in the\n> first place: you have a namespace in which there is no chance for\n> 'git-fetch' to overwrite local changes (ancient git had no such\n> namespace).\n\nOk, so a remote tracking branch is a forcefully merged branch, so we\nput it into a separate category where we won't get tempted to have a\nbranch head which will get overwritten.\n\nThis whole \"remote tracking\" appears to be more a matter of _policy_\nrather than inherent design. It would appear that local and remote\ntracking branches have no fundamental differences, they just get\ndifferent defaults which make it less likely for the first to lose\nlocal changes, and less likely for the second to miss remote changes\n(in particular where those involve messing up the history).\n\nBut it would be easy to create chimeras when working outside of the\nporcelain, right?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49737","messageId":"85k5sbfhnw.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070804104851.162d7e00.seanlkml@sympatico.ca","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T15:22:59Z","receivedAt":"2007-08-04T15:22:59Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Sean writes:\n\n> On Sat, 04 Aug 2007 16:01:55 +0200\n> David Kastrup wrote:\n>\n>> So --track does not set up a tracking branch, but makes a local\n>> _following_ branch _refer_ to a tracking branch.\n>\n> Sure, that's one way to describe it; perhaps it would be best if\n> we switched to that nomenclature in the documentation.\n\nNot according to my current understanding, but that can, of course,\nchange again in the next few hours. As far as I understand right now,\nsuch a branch indeed tracks a remote branch (and not a remote tracking\nbranch), it just does not track it recklessly: it has a head of its\nown, and it won't use git-fetch -f for updating it.\n\n> It's not a problem, you could just add an appropriate [branch...] section\n> in your .git/config. Actually looking at a typical branch section\n> is even more confusing to me:\n>\n> $ git branch fudge origin/fix1\n>\n> adds this to the .git/config:\n>\n> [branch \"fudge\"]\n> remote = origin\n> merge = refs/heads/fix1\n>\n> The config file does not record the remote-tracking-branch, instead\n> it explicitly records the remote repository information. So it sure\n> appears that if you add the --track option, it _does_ make the local\n> branch track a remote directly. Thus it's hard to call it anything\n> but what you labelled it, a local tracking-branch.\n\nYes, it seems --track does track after all. Just more cautiously than\na remote tracking branch does.\n\n> While I thought i had a handle on this, i'm now officially more\n> confused than you;\n\nGood. It means that I may not be a complete idiot. It may also mean\nthat the documentation can be improved in places. With a lot of\n\"grep\" and fine-combing I realized that quite a bit of the information\n_is_ \"available\" (and some conflicting information as well).\n\nThis is one reason why I would prefer to have something like a typical\nTexinfo manual, at least on the organisational level: a manual is\nsupposed to present a single connected view to the available\ndocumentation. And the information for git is scattered through a\nbunch of mostly disconnected files.\n\nIf you want to see a more staggering example of this approach, take a\nlook at the \"guilt\" documentation. It consists only of the man pages\nfor the individual commands, and then some few README-like files which\nmostly say something like \"guilt is just like quilt, or like\nMercurial's patch sets\". That's rather extreme as far as\nuser-accessible information goes. git has a few more generally useful\nfiles explaining underlying concepts, but they still are basically\nthrown into one large self-service heap, not a coherent document.\n\n> hopefully someone with knowledge of the guts of Git will speak up.\n\nI think I am slowly getting it, thanks to Lars and others.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49741","messageId":"8c5c35580708040848u78c4a913tf650325fff6a0bb7@mail.gmail.com","threadId":"9379","inReplyTo":"85odhnfiau.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-08-04T15:48:03Z","receivedAt":"2007-08-04T15:48:03Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 8/4/07, David Kastrup wrote:\n> This whole \"remote tracking\" appears to be more a matter of _policy_\n> rather than inherent design.\n\nAbsolutely.\n\n> It would appear that local and remote\n> tracking branches have no fundamental differences\n\nI'd say they have no differences at all, it's just that\n'git-checkout.sh' will refuse to update HEAD to point at something\noutside of refs/heads.\n\n-- \nlarsh\n"},{"id":"49755","messageId":"85r6mjdyl8.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"8c5c35580708040607ya186edcg89fbc90587b64d68@mail.gmail.com","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T17:00:19Z","receivedAt":"2007-08-04T17:00:19Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Lars Hjemli\" writes:\n\n> The magic setup that makes this happen is the following lines in .git/config:\n>\n> [remote \"origin\"]\n> url = git://git.kernel.org/pub/scm/git/git.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n>\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n>\n>\n> Was this helpful?\n\nIt would be helpful. Except that nothing whatsoever can be found in\n.git/config concerning my local and my remote tracking branches. So\nwhere is that information _really_ hidden away?\n\n.git/FETCH_HEAD maybe?\n\nIt also appears that doing\n\ngit-checkout --track -b mybranch origin\n\non a git.git clone does _not_ create a tracking branch. I can't\nfigure out what I could specify as an origin to create a tracking\nbranch that would get reflected in .git/FETCH_HEAD.\n\nWhat gives?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49757","messageId":"Pine.LNX.4.64.0708041804260.13596@beast.quantumfyre.co.uk","threadId":"9379","inReplyTo":"85r6mjdyl8.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-08-04T17:19:26Z","receivedAt":"2007-08-04T17:19:26Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sat, 4 Aug 2007, David Kastrup wrote:\n\n> \"Lars Hjemli\" writes:\n>\n>> The magic setup that makes this happen is the following lines in .git/config:\n>>\n>> [remote \"origin\"]\n>> url = git://git.kernel.org/pub/scm/git/git.git\n>> fetch = +refs/heads/*:refs/remotes/origin/*\n>>\n>> [branch \"master\"]\n>> remote = origin\n>> merge = refs/heads/master\n>>\n>>\n>> Was this helpful?\n>\n> It would be helpful. Except that nothing whatsoever can be found in\n> .git/config concerning my local and my remote tracking branches. So\n> where is that information _really_ hidden away?\n\nIt really is in .git/config, _provided_ that your repo was created by \n1.5.0 or newer. Older versions had a more distributed setup using files \nin .git/remotes/ and .git/branches/\n\n> .git/FETCH_HEAD maybe?\n\nNope, that's just information about what got fetched last. A purely \ntemporary thing.\n\n> It also appears that doing\n>\n> git-checkout --track -b mybranch origin\n>\n> on a git.git clone does _not_ create a tracking branch. I can't\n> figure out what I could specify as an origin to create a tracking\n> branch that would get reflected in .git/FETCH_HEAD.\n\nWith pre 1.5 you didn't get remote tracking branches in a separate \nnamespace. The default was to have a local branch called origin which was \nthe \"remote tracking branch\" for the master branch - but this wasn't \nenforced. So with your repo the origin branch _is_ the remote tracking \nbranch ... or at least the closet a pre 1.5 setup gets.\n\n> What gives?\n\nIt would appear that your repo was created with an old version of git. \nWhich also explains why you were talking about origin as a branch - which \nit used to be (a real local branch too ...), rather than as a remote - \nwhich it is now.\n\nThe whole remotes/tracking mechanism changed in 1.5.0 - now it's much more \nflexible (and probably more complicated too).\n\n-- \nJulian\n\n ---\nEver notice that even the busiest people are never too busy to tell you\njust how busy they are?\n"},{"id":"49765","messageId":"85hcnfdvtr.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"Pine.LNX.4.64.0708041804260.13596@beast.quantumfyre.co.uk","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-04T18:00:00Z","receivedAt":"2007-08-04T18:00:00Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Julian Phillips writes:\n\n> On Sat, 4 Aug 2007, David Kastrup wrote:\n>\n>> \"Lars Hjemli\" writes:\n>>\n>>> The magic setup that makes this happen is the following lines in .git/config:\n>> It would be helpful. Except that nothing whatsoever can be found in\n>> .git/config concerning my local and my remote tracking branches. So\n>> where is that information _really_ hidden away?\n>\n>> What gives?\n>\n> It would appear that your repo was created with an old version of\n> git. Which also explains why you were talking about origin as a\n> branch - which it used to be (a real local branch too ...), rather\n> than as a remote - which it is now.\n>\n> The whole remotes/tracking mechanism changed in 1.5.0 - now it's\n> much more flexible (and probably more complicated too).\n\nI think I am going to cry. So I need to rebase my branches, pull out\nthe resulting patch sets, scrap my repository, clone it new from\nupstream, reapply my branches, in order to have a system where the\ndocumentation is somewhat in synch with the actual behavior?\n\n[...]\n\nNo, it would seem that I can just\ngit-clone -l\nmy repository and be set up in the new order of things. Nice.\n\nHowever, it would appear from my experiments up to now that the\n--track option _can't_ be made to work with a 1.4 repository. I think\nthat is worth mentioning in the docs.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49790","messageId":"20070804225655.GD11150@thunk.org","threadId":"9379","inReplyTo":"85hcnfdvtr.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-08-04T22:56:55Z","receivedAt":"2007-08-04T22:56:55Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Aug 04, 2007 at 08:00:00PM +0200, David Kastrup wrote:\n> \n> I think I am going to cry. So I need to rebase my branches, pull out\n> the resulting patch sets, scrap my repository, clone it new from\n> upstream, reapply my branches, in order to have a system where the\n> documentation is somewhat in synch with the actual behavior?\n\n... or you can you use \"git remote\" to create the remote tracking\nbranches. The important thing to realize is that 99% of what \"git\nremote\" does is purely by editing the config file. (The last 1% is\nrunning \"git fetch\" if you specify the -f option.) So understanding\nwhat gets placed in the .git/config file after doing an initial clone\nfrom a URL for a pre-1.5 git and what gets placed in .git/config file\nand how the branches are set up post 1.5 is key to understanding what\nis going on.\n\n> No, it would seem that I can just\n> git-clone -l\n> my repository and be set up in the new order of things. Nice.\n\nBe careful, not really. A git-clone -l will set up a new repository\nwhere origin/master is your original repository, i.e.:\n\n[remote \"origin\"]\n url = /usr/projects/e2fsprogs/base\n fetch = +refs/heads/*:refs/remotes/origin/*\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nIn contrast, if you had done a git-clone of remote repository, you\nmight see something like this instead:\n\n[remote \"origin\"]\n url = git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nIn contrast, if you are using git 1.4, after a clone, \"origin\" and\n\"master\" are by default set to the \"master\" branch in the source\nrepository, and in git 1.4 (and in git 1.5 if you don't have any of\nthe above configuration opions in your .git/config file), the \"origin\"\nbranch is magical and works like the remote tracking branch of\norigin/master of git 1.5 for the purposes of \"git fetch\", and then the\nimplied merge done by \"git pull\" merges from \"origin\" branch to the\n\"master\" branch.\n\n> However, it would appear from my experiments up to now that the\n> --track option _can't_ be made to work with a 1.4 repository. I think\n> that is worth mentioning in the docs.\n\nWell, there really is no such thing as a \"1.4 repository\". The only\nreal difference is the default configuration which is dropped into the\n.config file when you do a \"git clone\", and whether the head of the\nmaster branch created after the \"git clone\" is called \"origin\", with\nsome magic special casing so that works like a remote tracking branch\nof the remote repo's master branch, or whether it is called\n\"origin/master\", with explicit configuration rules in .git/config.\n\nThe real issue is that a \"1.4 repository\" (that is a repository\ncreated by \"git clone\" from git 1.4 and where the config file hasn't\nbeen updated either by hand-editing the config file or by use of \"git\nconfig\" or \"git remote\" to have remote branches) doesn't have any\nremote branches, and git branch -track only has significance if you\nare creating a new (local) branch from a remote tracking branch.\n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"49830","messageId":"85k5sacvf3.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070804225655.GD11150@thunk.org","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-05T07:06:24Z","receivedAt":"2007-08-05T07:06:24Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Theodore Tso writes:\n\n> On Sat, Aug 04, 2007 at 08:00:00PM +0200, David Kastrup wrote:\n>\n>> No, it would seem that I can just\n>> git-clone -l\n>> my repository and be set up in the new order of things. Nice.\n>\n> Be careful, not really. A git-clone -l will set up a new repository\n> where origin/master is your original repository, i.e.:\n>\n> [remote \"origin\"]\n> url = /usr/projects/e2fsprogs/base\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n>\n> In contrast, if you had done a git-clone of remote repository, you\n> might see something like this instead:\n\nYes, I noticed. I can do a\ngit-clone -l --reference /my/local/rep git://the/remote/repo\n\ninstead. That's still very fast, but I miss out on my local changes...\n\n> [remote \"origin\"]\n> url = git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n>\n>> However, it would appear from my experiments up to now that the\n>> --track option _can't_ be made to work with a 1.4 repository. I think\n>> that is worth mentioning in the docs.\n>\n> The real issue is that a \"1.4 repository\" (that is a repository\n> created by \"git clone\" from git 1.4 and where the config file hasn't\n> been updated either by hand-editing the config file or by use of\n> \"git config\" or \"git remote\" to have remote branches) doesn't have\n> any remote branches, and git branch -track only has significance if\n> you are creating a new (local) branch from a remote tracking branch.\n\nAn error message might be nice, though. I find git hard to understand\nat times.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49832","messageId":"7v8x8qfnev.fsf@assigned-by-dhcp.cox.net","threadId":"9379","inReplyTo":"854pjfin68.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-05T07:31:04Z","receivedAt":"2007-08-05T07:31:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> I am trying to dig through man-pages and user manual and trying to\n> match them with reality. I seem to have a hard time. My current\n> understanding (which definitely differs from the documented state) is\n> that there are two types of branches, local and remote branches, and\n> both types of branches can be remote-tracking (it may not be possible\n> to have a non-remote-tracking remote branch, though).\n\nI think we have a brief discussion on #git before you brought\nthis up ;-)\n\n - local branches -- we know what they are.\n\n - remote tracking branches -- refs that appear in refs/remotes/\n in the current world order; they are updated only by copying\n the corresponding local branches at the remote site, and are\n meant to \"keep track of what _they_ are doing\". In olden\n days before 1.5.0 with non separate remote layout,\n 'refs/heads/origin' branch, and all the non default branches,\n were treated this way as well. You were not supposed to make\n commit on them (because of the above \"keep track of\" reason),\n and having them under refs/heads were too confusing, which\n was the reason the separate remote layout was invented.\n\nYou can have a local branch that is created by forking off of a\nremote tracking branch, with the intention to \"build on top\" of\nthe corresponding remote tracking brach. You can create such a\nbranch and mark it as such with --track option introduced in\nv1.5.1 timeperiod. This is a relatively new concept, but many\npeople find it useful. We do not have the official term to call\nthis concept, and some people have misused the term \"remote\ntracking branches\" to describe this, which made things very\nconfusing.\n\nWe would need an official terminology for it.\n"},{"id":"49841","messageId":"20070805092115.GA12507@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85tzrfh3yg.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T09:21:15Z","receivedAt":"2007-08-05T09:21:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 04, 2007 at 02:36:07PM +0200, David Kastrup wrote:\n\n> And it's actually worse after your explanations. Previously I\n> imagined to have a chance to figure this out on my own, by trying to\n> abstract from what I see happening when using the various commands.\n> \n> Now I think that I basically have no chance figuring this out on my\n> own sufficiently well to be able to improve the documentation.\n\nI see that Lars and others have provided some explanations in my\nabsence, but let me try to lay it out from basics, and hopefully between\nall of our writing it will make sense. I'm going to try to be as basic\nas possible, so if I am telling you something you already know, it's not\nbecause I think you're stupid, but because I'm trying to be thorough.\n\nGit history is a directed graph of commit objects, with each commit\nobject pointing to its parent (or parents if it is a merge). We have\nhuman-readable names pointing into the history as well, which we call\nrefs, and generally store under the \"refs/\" hierarchy (with a few\nexceptions, which I will mention in a minute).\n\nThere are a few different types of pointers (refs) that are useful to\nus. They are differentiated by the types of things we want to do with\nthem.\n\n 1. refs that track our ongoing commits. This process involves making\n a new commit object whose parent is the previous value of the ref,\n and then pointing the ref at the new commit. We generally call\n these refs \"heads\", \"local branches\", or just \"branches\", and they\n are stored in \"refs/heads/\".\n\n 2. refs that point to a single commit and aren't changed. These refs\n are \"tags\", and we store them in \"refs/tags/\".\n\n 3. refs that represent a remote repository's local branch. These are\n updated by git-fetch, which simply writes the new value of the\n pointer into our local copy, throwing out the old value. These are\n called \"remote tracking branches\" and are stored in\n \"refs/remotes//\".\n\n 4. Temporary pointers to help out some multi-step operation that we're\n in the middle of. These include FETCH_HEAD and MERGE_HEAD.\n\nThere is an order of ref lookup which goes like:\n .git/\n .git/refs/\n .git/refs/tags/\n .git/refs/heads/\n .git/refs/remotes/\n\nIt used to be the case (prior to git 1.5) that remote tracking branches\nand local branches were stored in the same hierarchy (under\nrefs/heads/). This turned out to be problematic for many users, because\nthe operations that you perform on them don't play well together.\n\nFor example, let's say you have a branch \"origin\" representing Junio's\n\"master\" branch. You check it out and make a commit. This rewrites the\n\"origin\" ref, but it's safe because the new commit points to the old\nvalue. Now you want to fetch more work from Junio, so you run\n\"git-fetch\". But the value of Junio's ref doesn't ever reference your\nwork. If git-fetch copies the value of Junio's new ref into your\n\"origin\", then it will throw away the work that you were done (i.e., no\nref will be pointing to it, or to any commit that references it). But if\ngit-fetch doesn't copy the value of Junio's new ref, then how will you\nget to see his new work?\n\nSo it is a mistake to create commits on top of a remote tracking branch.\nThe new strategy is therefore to store them in refs/remotes, which is an\nindicator that they are purely for remote tracking. If you attempt to\ngit-checkout a branch in refs/remotes, you will get a detached HEAD\nrather than actually checking out that branch.\n\nNormally \"HEAD\" is a pointer to a ref in refs/heads/ (which is itself a\npointer to a commit object) representing \"the current branch.\" When HEAD\nbecomes detached, we mean that instead of pointing to a branch ref, it\npoints directly to a commit object. So when you do \"git-checkout\norigin/master\" (which, unless you have a local branch named\n\"origin/master\" will end up looking in refs/remotes/origin/master), it\ndoesn't put \"refs/remotes/origin/master\" in your HEAD, but rather the\n_value_ of that ref.\n\nThe implication here is that commits you create on a detached HEAD are\nnot stored by any ref except HEAD, and will be lost when you move\nthe HEAD elsewhere (i.e., when you check out a different branch).\n\nTags are in a similar situation. You don't want to make commits on tags;\ninstead, you want to simply set them to a pre-existing commit. Thus when\nyou check out a tag, you get a detached HEAD (and we know it's a tag\nbecause it's in refs/tags, not refs/heads).\n\nSo hopefully at this point you understand \"local branch\" and \"remote\ntracking branch.\"\n\nTo get to the final concept you mentioned, let's take a look at what\nfetch and pull do.\n\nLet's say you run:\n\n git-fetch git://git.kernel.org/pub/scm/git/git.git\n\nThat stores the value of Junio's current branch (which tends to be\n\"master\") into your local FETCH_HEAD (stored in \".git/FETCH_HEAD\").\n\nAnd if you run:\n\n git-fetch git://git.kernel.org/pub/scm/git/git.git next\n\nThen we store the value of Junio's next branch into your FETCH_HEAD.\n\nAnd finally, if you run:\n\n git-fetch \\\n git://git.kernel.org/pub/scm/git/git.git \\\n next:refs/remotes/junio/next\n\nthen we store Junio's next branch in our FETCH_HEAD, but _also_ store it\nin the remote tracking branch refs/remotes/junio/next.\n\nThe second argument to fetch is called a \"refspec\", and you can have\nseveral of them. Because all of that gets tedious to type, we have the\nconcept of configured remotes, which are a shorthand for a URL and\nassociated refspecs. When you use \"git-clone\", it creates the following\nconfig:\n\n [remote \"origin\"]\n url = git://git.kernel.org/pub/scm/git/git.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n\nThe refspec in this case uses a wildcard to get _all_ of Junio's\nbranches, and store them by name under refs/remotes/origin. So we can\njust say \"git-fetch origin\" and it will populate our FETCH_HEAD as well\nas the refs/remotes/origin directory.\n\nIf we call \"git-fetch\" without any arguments, it will look up the\ndefault remote in our configuration. git-clone also creates the\nfollowing config:\n\n [branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nwhich means \"if we are on the master branch, default fetches to the\nremote 'origin'\". I will explain the merge line in a minute.\n\nSo now we look at git-pull. Recall that a pull is basically a fetch\nfollowed by a merge. If you run:\n\n git-pull git://git.kernel.org/pub/scm/git/git.git\n\nit will do a git-fetch of that URL (grabbing the current branch),\nfollowed by a git-merge of FETCH_HEAD.\n\nIf you run:\n\n git-pull origin master\n\nit will fetch the \"origin\" remote, putting all branches into the\nFETCH_HEAD (and storing them in refs/remotes/origin as a side effect).\nThen it will pick the branch named 'master' out of FETCH_HEAD, and\nmerge it.\n\nIf you run:\n\n git-pull origin\n\nit will fetch origin as usual, but which branch gets merged? The answer\nis the value of the \"merge\" field in the 'branch \"master\"' section of\nyour config (which is generally created by git-clone).\n\nAnd of course, if you run:\n\n git-pull\n\nit will look up the remote to fetch in the config (just as \"git-fetch\"\nwould), and then find the branch to merge in the config.\n\nSo how do we this configuration set up? There are three ways:\n\n 1. Edit your .git/config by hand. :)\n 2. git-clone sets up a master/origin relationship, adding both the\n \"remote\" and \"branch\" sections.\n 3a. Using git-remote, you can add new \"remote\" sections easily.\n 3b. Using the --track option to git-branch, you can set up the\n \"branch\" section automatically.\n\nWhat you had called a \"remote-tracking branch\" is really a branch for\nwhich the 'branch \"\"' config section has been set up (which could\ncome about in several ways). I haven't really seen a term such as\n\"remote-tracking branch\" for this in use in the documentation (and I\nthink we both agree that is not the right term because of its confusing\nsimilarity to remote tracking branches, discussed above).\n\nI know that was a pretty long email, but hopefully you understand the\ncontext of the terms a bit more, and I didn't bore you too much. ;)\nFeel free to ask questions if there are parts that are unclear.\n\n-Peff\n"},{"id":"49842","messageId":"20070805092451.GB12507@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85odhnfiau.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T09:24:51Z","receivedAt":"2007-08-05T09:24:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 04, 2007 at 05:09:13PM +0200, David Kastrup wrote:\n\n> Ok, so a remote tracking branch is a forcefully merged branch, so we\n> put it into a separate category where we won't get tempted to have a\n> branch head which will get overwritten.\n\nI would hesitate to use the word \"merge\" here at all. You really are\njust throwing away the old value, and overwriting it with the new value.\nSee my other email for more details.\n\n> This whole \"remote tracking\" appears to be more a matter of _policy_\n> rather than inherent design. It would appear that local and remote\n> tracking branches have no fundamental differences, they just get\n> different defaults which make it less likely for the first to lose\n> local changes, and less likely for the second to miss remote changes\n> (in particular where those involve messing up the history).\n\nYes, I think that's fair to say.\n\n> But it would be easy to create chimeras when working outside of the\n> porcelain, right?\n\nSure, but then you are responsible for the mess it creates. :)\n\n-Peff\n"},{"id":"49843","messageId":"85myx6ba8n.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070805092115.GA12507@coredump.intra.peff.net","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-05T09:29:12Z","receivedAt":"2007-08-05T09:29:12Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n[...]\n\n> I know that was a pretty long email, but hopefully you understand\n> the context of the terms a bit more, and I didn't bore you too\n> much. ;) Feel free to ask questions if there are parts that are\n> unclear.\n\nThe main question is why I can't find this explained in this manner in\nthe documentation. Are you going to put it in yourself, or should I\nattempt doing it?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49845","messageId":"20070805093232.GC12507@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85myx6ba8n.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T09:32:32Z","receivedAt":"2007-08-05T09:32:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 05, 2007 at 11:29:12AM +0200, David Kastrup wrote:\n\n> The main question is why I can't find this explained in this manner in\n> the documentation. Are you going to put it in yourself, or should I\n> attempt doing it?\n\nI guess because nobody complained it wasn't there before. :) Some of the\ninformation is a bit under-the-hood for most end-users, but obviously in\nyour case the lack of information was creating confusion about the\nterms.\n\nWhy don't you take a stab at updating the documentation (since you are\nthe one who knows which parts were confusing you), and I will be more\nthan happy to help with making sure the changes are accurate.\n\n-Peff\n"},{"id":"49849","messageId":"85fy2yb9jn.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070805093232.GC12507@coredump.intra.peff.net","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-05T09:44:12Z","receivedAt":"2007-08-05T09:44:12Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n> On Sun, Aug 05, 2007 at 11:29:12AM +0200, David Kastrup wrote:\n>\n>> The main question is why I can't find this explained in this manner in\n>> the documentation. Are you going to put it in yourself, or should I\n>> attempt doing it?\n>\n> I guess because nobody complained it wasn't there before. :) Some of the\n> information is a bit under-the-hood for most end-users, but obviously in\n> your case the lack of information was creating confusion about the\n> terms.\n>\n> Why don't you take a stab at updating the documentation (since you are\n> the one who knows which parts were confusing you),\n\nWell, one problem is that there simply _is_ no part of the\ndocumentation where such an explanation would have a place. It does\nnot fit in the man pages of git-branch/git-commit, it has some passing\nrelation to the repository layout explanation (even though the latter\nshould not be something that the user has to read and understand for\nbasic operation), it may have some place in the user manual, but may\nbe a bit technical/long for that. Or one places it into another\nisolated file and hopes that a user will stumble across it when in\nneed of the information.\n\nHm. Probably the usermanual is the best option in the current scheme\nof things.\n\n> and I will be more than happy to help with making sure the changes\n> are accurate.\n\nThanks.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49850","messageId":"20070805094648.GA15676@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85fy2yb9jn.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T09:46:48Z","receivedAt":"2007-08-05T09:46:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 05, 2007 at 11:44:12AM +0200, David Kastrup wrote:\n\n> Well, one problem is that there simply _is_ no part of the\n> documentation where such an explanation would have a place. It does\n> [...]\n> Hm. Probably the usermanual is the best option in the current scheme\n> of things.\n\nI'm not too familiar with the usermanual, it having come about long\nafter I started with git. But I wonder if a subsection on \"refs\" under\nthe \"Git internals\" section might make sense.\n\n-Peff\n"},{"id":"49854","messageId":"20070805100532.GG12507@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85ejijgzzg.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T10:05:32Z","receivedAt":"2007-08-05T10:05:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 04, 2007 at 04:01:55PM +0200, David Kastrup wrote:\n\n> So --track does not set up a tracking branch, but makes a local\n> _following_ branch _refer_ to a tracking branch.\n\nA minor nit, but --track sets up a local following branch to refer to a\nremote's branch, _not_ to the tracking branch. In other words, if you\nlook at the config:\n\n [branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nIt does _not_ reference the tracking branch\n\"refs/remotes/origin/master\", but rather the remote's name for the\nbranch \"refs/heads/master\".\n\nThere was much discussion of this topic, but the general idea was not to\nrequire remote tracking branches for this feature to be used (a position\nI somewhat disagree with, but then I'm not the maintainer).\n\n-Peff\n"},{"id":"49855","messageId":"2D72EA7C-C77E-4B67-A8FD-EE610F5DC161@zib.de","threadId":"9379","inReplyTo":"7v8x8qfnev.fsf@assigned-by-dhcp.cox.net","subject":"Re: Terminology question about remote branches.","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-05T10:07:56Z","receivedAt":"2007-08-05T10:07:56Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 5, 2007, at 9:31 AM, Junio C Hamano wrote:\n\n> David Kastrup writes:\n>\n>> I am trying to dig through man-pages and user manual and trying to\n>> match them with reality. I seem to have a hard time. My current\n>> understanding (which definitely differs from the documented state) is\n>> that there are two types of branches, local and remote branches, and\n>> both types of branches can be remote-tracking (it may not be possible\n>> to have a non-remote-tracking remote branch, though).\n>\n> I think we have a brief discussion on #git before you brought\n> this up ;-)\n>\n> - local branches -- we know what they are.\n>\n> - remote tracking branches -- refs that appear in refs/remotes/\n> in the current world order; they are updated only by copying\n> the corresponding local branches at the remote site, and are\n> meant to \"keep track of what _they_ are doing\". In olden\n> days before 1.5.0 with non separate remote layout,\n> 'refs/heads/origin' branch, and all the non default branches,\n> were treated this way as well. You were not supposed to make\n> commit on them (because of the above \"keep track of\" reason),\n> and having them under refs/heads were too confusing, which\n> was the reason the separate remote layout was invented.\n\nThe current user manual defines this case in the glossary as\n'tracking branch' (without remote), but mostly uses\n'remote-tracking branch' at other places. Tracking branch\nand remote-tracking branch seem to be equivalent. And I think\nwe should leave it this way.\n\n\n> You can have a local branch that is created by forking off of a\n> remote tracking branch, with the intention to \"build on top\" of\n> the corresponding remote tracking brach. You can create such a\n> branch and mark it as such with --track option introduced in\n> v1.5.1 timeperiod. This is a relatively new concept, but many\n> people find it useful. We do not have the official term to call\n> this concept, and some people have misused the term \"remote\n> tracking branches\" to describe this, which made things very\n> confusing.\n>\n> We would need an official terminology for it.\n\nSomething like 'automerging branch', and replace options with\n'--automerge/--no-automerge'?\n\nI'm not fully convinced of this idea because it may be\ntechnically correct but doesn't really reflect the intention of\n'building on top' of the remote tracking branch.\n\n\tSteffen\n"},{"id":"49856","messageId":"20070805101053.GH12507@coredump.intra.peff.net","threadId":"9379","inReplyTo":"20070804104851.162d7e00.seanlkml@sympatico.ca","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T10:10:53Z","receivedAt":"2007-08-05T10:10:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 04, 2007 at 10:48:51AM -0400, Sean wrote:\n\n> The config file does not record the remote-tracking-branch, instead\n> it explicitly records the remote repository information. So it sure\n> appears that if you add the --track option, it _does_ make the local\n> branch track a remote directly. Thus it's hard to call it anything\n> but what you labelled it, a local tracking-branch.\n> \n> While I thought i had a handle on this, i'm now officially more\n> confused than you; hopefully someone with knowledge of the guts\n> of Git will speak up. Junio Help!\n\nThere is some discussion in this thread:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/35090/focus=35265\n\n-Peff\n"},{"id":"49862","messageId":"85172807-B7EB-47DD-813E-FAF5894E1190@zib.de","threadId":"9379","inReplyTo":"20070805100532.GG12507@coredump.intra.peff.net","subject":"Re: Terminology question about remote branches.","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-05T10:56:49Z","receivedAt":"2007-08-05T10:56:49Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 5, 2007, at 12:05 PM, Jeff King wrote:\n\n> On Sat, Aug 04, 2007 at 04:01:55PM +0200, David Kastrup wrote:\n>\n>> So --track does not set up a tracking branch, but makes a local\n>> _following_ branch _refer_ to a tracking branch.\n>\n> A minor nit, but --track sets up a local following branch to refer \n> to a\n> remote's branch, _not_ to the tracking branch. In other words, if you\n> look at the config:\n>\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n>\n> It does _not_ reference the tracking branch\n> \"refs/remotes/origin/master\", but rather the remote's name for the\n> branch \"refs/heads/master\".\n>\n> There was much discussion of this topic, but the general idea was \n> not to\n> require remote tracking branches for this feature to be used (a \n> position\n> I somewhat disagree with, but then I'm not the maintainer).\n\nInteresting. I didn't even recognize this detail up to know. It was \nsomewhat\nbeyond my imagination that I could have a local following/automerging\nbranch that is directly referring to a branch in a remote repo, without\nhave a remote-tracking branch.\n\nHow could I create such a setup in the first place?\n\n git branch --track something origin/something\n git checkout --track -b something origin/something\n\nare obvious, but what to say if I don't have origin/something?\n\n\tSteffen\n"},{"id":"49865","messageId":"20070805110200.GA18083@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85172807-B7EB-47DD-813E-FAF5894E1190@zib.de","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T11:02:00Z","receivedAt":"2007-08-05T11:02:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 05, 2007 at 12:56:49PM +0200, Steffen Prohaska wrote:\n\n> beyond my imagination that I could have a local following/automerging\n> branch that is directly referring to a branch in a remote repo, without\n> have a remote-tracking branch.\n>\n> How could I create such a setup in the first place?\n>\n> git branch --track something origin/something\n> git checkout --track -b something origin/something\n>\n> are obvious, but what to say if I don't have origin/something?\n\nI believe the --track setup uses the tracking branches to figure out\nwhich remote/branch combo to track. To do it without a remote tracking\nbranch, you would have to add the lines to your .git/config manually.\n\n-Peff\n"},{"id":"49869","messageId":"85tzre8b4w.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070805110200.GA18083@coredump.intra.peff.net","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-05T11:38:07Z","receivedAt":"2007-08-05T11:38:07Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n> On Sun, Aug 05, 2007 at 12:56:49PM +0200, Steffen Prohaska wrote:\n>\n>> beyond my imagination that I could have a local following/automerging\n>> branch that is directly referring to a branch in a remote repo, without\n>> have a remote-tracking branch.\n>>\n>> How could I create such a setup in the first place?\n>>\n>> git branch --track something origin/something\n>> git checkout --track -b something origin/something\n>>\n>> are obvious, but what to say if I don't have origin/something?\n>\n> I believe the --track setup uses the tracking branches to figure out\n> which remote/branch combo to track. To do it without a remote tracking\n> branch, you would have to add the lines to your .git/config manually.\n\nFascinating, really fascinating. Is there actually _anybody_ who\nwould not revert to phrases like \"I believe\" when describing git's\ninteraction with remote branches?\n\nI don't find this particularly logical: origin/something basically\nboils down referring to a commit.\n\nMaybe git-branch --track should allow referring to remote:branch or\nURLs or something directly rather than a remote tracking branch?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49871","messageId":"20070805115208.GA19734@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85tzre8b4w.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T11:52:08Z","receivedAt":"2007-08-05T11:52:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 05, 2007 at 01:38:07PM +0200, David Kastrup wrote:\n\n> > I believe the --track setup uses the tracking branches to figure out\n> > which remote/branch combo to track. To do it without a remote tracking\n> > branch, you would have to add the lines to your .git/config manually.\n> \n> Fascinating, really fascinating. Is there actually _anybody_ who\n> would not revert to phrases like \"I believe\" when describing git's\n> interaction with remote branches?\n\nBy \"I believe\", I meant \"I am pretty sure this is the way it is\nimplemented, but I have better things to do than read through\nbuiltin-branch.c right now, so please don't take this as gospel and go\nread the code yourself.\"\n\nBut the point of --track is that I don't _have_ to care, and that it\ndeduces the correct remote/branch combination itself.\n\n> I don't find this particularly logical: origin/something basically\n> boils down referring to a commit.\n\nReally, \"origin/something\" refers to \"refs/remotes/origin/something\",\nwhich we can deduce from the config to be populated by a particular\nremote and branch (go read the code).\n\n> Maybe git-branch --track should allow referring to remote:branch or\n> URLs or something directly rather than a remote tracking branch?\n\nIt could, but at that point, you could just do:\n\n git-branch newbranch oldbranch\n git-config branch.newbranch.remote someremote\n git-config branch.newbranch.merge remotebranch\n\nPerhaps it's slightly more convenient to be able to do\n\n git-branch --track someremote:remotebranch newbranch oldbranch\n\nbut the real convenience of --track is when it deduces those parameters\nitself.\n\n-Peff\n"},{"id":"49874","messageId":"85fy2y89kb.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070805115208.GA19734@coredump.intra.peff.net","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-05T12:12:04Z","receivedAt":"2007-08-05T12:12:04Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n> On Sun, Aug 05, 2007 at 01:38:07PM +0200, David Kastrup wrote:\n>\n>> > I believe the --track setup uses the tracking branches to figure out\n>> > which remote/branch combo to track. To do it without a remote tracking\n>> > branch, you would have to add the lines to your .git/config manually.\n>> \n>> Fascinating, really fascinating. Is there actually _anybody_ who\n>> would not revert to phrases like \"I believe\" when describing git's\n>> interaction with remote branches?\n>\n> By \"I believe\", I meant \"I am pretty sure this is the way it is\n> implemented, but I have better things to do than read through\n> builtin-branch.c right now, so please don't take this as gospel and go\n> read the code yourself.\"\n\nWell, that is pretty much exactly what I find fascinating: that the\nbehavior is arbitrary and undocumented enough that one can't deduce it\neither by logic or by recollection or by documentation, but just by\nreading the code.\n\nUsually code is supposed to implement a design, but here it seems\nrather like the design, if there is any, is to be abstracted from the\ncode.\n\nMaybe I get fascinated too easily.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49875","messageId":"20070805121409.GA19885@coredump.intra.peff.net","threadId":"9379","inReplyTo":"85fy2y89kb.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T12:14:09Z","receivedAt":"2007-08-05T12:14:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 05, 2007 at 02:12:04PM +0200, David Kastrup wrote:\n\n> Well, that is pretty much exactly what I find fascinating: that the\n> behavior is arbitrary and undocumented enough that one can't deduce it\n> either by logic or by recollection or by documentation, but just by\n> reading the code.\n\nI see your point, but I think you are reading too much into my words. I\nam 99% sure that is the way it works (because it would make no sense to\nwork any other way, and that is my mental model of how it works), but I\nam very hesitant to state something outright which I haven't\ndouble-checked in the code. Thus I used weak language.\n\n-Peff\n"},{"id":"49895","messageId":"Pine.LNX.4.64.0708051519400.7631@beast.quantumfyre.co.uk","threadId":"9379","inReplyTo":"7v8x8qfnev.fsf@assigned-by-dhcp.cox.net","subject":"Re: Terminology question about remote branches.","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-08-05T14:23:12Z","receivedAt":"2007-08-05T14:23:12Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 5 Aug 2007, Junio C Hamano wrote:\n\n> David Kastrup writes:\n>\n>> I am trying to dig through man-pages and user manual and trying to\n>> match them with reality. I seem to have a hard time. My current\n>> understanding (which definitely differs from the documented state) is\n>> that there are two types of branches, local and remote branches, and\n>> both types of branches can be remote-tracking (it may not be possible\n>> to have a non-remote-tracking remote branch, though).\n>\n> I think we have a brief discussion on #git before you brought\n> this up ;-)\n>\n> - local branches -- we know what they are.\n>\n> - remote tracking branches -- refs that appear in refs/remotes/\n> in the current world order; they are updated only by copying\n> the corresponding local branches at the remote site, and are\n> meant to \"keep track of what _they_ are doing\". In olden\n> days before 1.5.0 with non separate remote layout,\n> 'refs/heads/origin' branch, and all the non default branches,\n> were treated this way as well. You were not supposed to make\n> commit on them (because of the above \"keep track of\" reason),\n> and having them under refs/heads were too confusing, which\n> was the reason the separate remote layout was invented.\n>\n> You can have a local branch that is created by forking off of a\n> remote tracking branch, with the intention to \"build on top\" of\n> the corresponding remote tracking brach. You can create such a\n> branch and mark it as such with --track option introduced in\n> v1.5.1 timeperiod. This is a relatively new concept, but many\n> people find it useful. We do not have the official term to call\n> this concept, and some people have misused the term \"remote\n> tracking branches\" to describe this, which made things very\n> confusing.\n>\n> We would need an official terminology for it.\n\nFollowing was mentioned earlier in this thread ... could we use that?\n\ntracking branch:\n ref always points at a commit from the remote repo branch\n\nfollowing branch:\n ref either points at a commit from the remote repo branch, or a\n local commit with a commit from the remote repo branch in the history\n\nperhaps?\n\n-- \nJulian\n\n ---\nAn optimist is a man who looks forward to marriage.\nA pessimist is a married optimist.\n"},{"id":"49903","messageId":"85ps226mrc.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"Pine.LNX.4.64.0708051519400.7631@beast.quantumfyre.co.uk","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-05T15:09:59Z","receivedAt":"2007-08-05T15:09:59Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Julian Phillips writes:\n\n> On Sun, 5 Aug 2007, Junio C Hamano wrote:\n>>\n>> I think we have a brief discussion on #git before you brought\n>> this up ;-)\n>>\n>> - local branches -- we know what they are.\n>>\n>> - remote tracking branches -- refs that appear in refs/remotes/\n>> in the current world order; they are updated only by copying\n>> the corresponding local branches at the remote site, and are\n>> meant to \"keep track of what _they_ are doing\". In olden\n>> days before 1.5.0 with non separate remote layout,\n>> 'refs/heads/origin' branch, and all the non default branches,\n>> were treated this way as well. You were not supposed to make\n>> commit on them (because of the above \"keep track of\" reason),\n>> and having them under refs/heads were too confusing, which\n>> was the reason the separate remote layout was invented.\n>>\n>> You can have a local branch that is created by forking off of a\n>> remote tracking branch, with the intention to \"build on top\" of\n>> the corresponding remote tracking brach. You can create such a\n>> branch and mark it as such with --track option introduced in\n>> v1.5.1 timeperiod. This is a relatively new concept, but many\n>> people find it useful. We do not have the official term to call\n>> this concept, and some people have misused the term \"remote\n>> tracking branches\" to describe this, which made things very\n>> confusing.\n>>\n>> We would need an official terminology for it.\n>\n> Following was mentioned earlier in this thread ... could we use that?\n>\n> tracking branch:\n> ref always points at a commit from the remote repo branch\n>\n> following branch:\n> ref either points at a commit from the remote repo branch, or a\n> local commit with a commit from the remote repo branch in the history\n>\n> perhaps?\n\nAn auto-merging branch? The term is somewhat more technical so that\npeople are less likely to think it just a colloquial alternative\nexpression for \"tracking\".\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49904","messageId":"Pine.LNX.4.64.0708051622290.10235@beast.quantumfyre.co.uk","threadId":"9379","inReplyTo":"85ps226mrc.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-08-05T15:24:28Z","receivedAt":"2007-08-05T15:24:28Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 5 Aug 2007, David Kastrup wrote:\n\n> Julian Phillips writes:\n>\n>> On Sun, 5 Aug 2007, Junio C Hamano wrote:\n>>> We would need an official terminology for it.\n>>\n>> Following was mentioned earlier in this thread ... could we use that?\n>>\n>> tracking branch:\n>> ref always points at a commit from the remote repo branch\n>>\n>> following branch:\n>> ref either points at a commit from the remote repo branch, or a\n>> local commit with a commit from the remote repo branch in the history\n>>\n>> perhaps?\n>\n> An auto-merging branch? The term is somewhat more technical so that\n> people are less likely to think it just a colloquial alternative\n> expression for \"tracking\".\n\nPersonally I don't like auto-merging as it doesn't have any connotations \nof _what_ is auto-merged ... and it's not really an automatic merge \nanyway, you have to ask for it (by running pull).\n\n-- \nJulian\n\n ---\nDon't look back, the lemmings are gaining on you.\n"},{"id":"49906","messageId":"20070805154801.GD28263@thunk.org","threadId":"9379","inReplyTo":"85fy2y89kb.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-08-05T15:48:01Z","receivedAt":"2007-08-05T15:48:01Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Aug 05, 2007 at 02:12:04PM +0200, David Kastrup wrote:\n> Well, that is pretty much exactly what I find fascinating: that the\n> behavior is arbitrary and undocumented enough that one can't deduce it\n> either by logic or by recollection or by documentation, but just by\n> reading the code.\n\nThe behavior of how references work and how the config file parameters\nunder remote.* and branch.* are pretty well understood, and the\nconceptual model is pretty simple; see Jeff's message. And most of it\n*is* documented if you look at the git-fetch, git-pull, git-config man\npages --- just not systematically in one place.\n\nWhat's not so well understood I suspect by most people is how the \"git\nbranch\" tool edits the config file. It was added later, and many of\nthe git hackers who already know the conceptual model and who are used\nto editing .git/config directly to get what they want, don't use git\nbranch much themselves; that's really for more novice users and more\nsimpler config files.\n\nTo use a GNU emacs example, consider M-x customize, which is this\nhuge, very fancy, *very* complex hierarchical mechanism with a\npointy-clicky interface for setting options. Most emacs experts\nwouldn't use it, preferring to open code raw emacs-lisp settings in\ntheir .emacs.el. If you ask an old-time emacs user how to set up some\nspecific feature setting via M-x customize, they might look at you\nblankly, because it's not an interface they use much, if at all.\n\nA similar thing can be said of \"git branch\"; once you are familiar\nwith how git works at a conceptual level, it can often be\nfaster/easier to just hack the .git/config file directly, instead of\nusing \"git branch\" to set up things the way you want. And I'm pretty\nsure there are ways to set up the config file when you edit it by hand\nthat you can't set up via \"git branch\".\n\n\t\t\t\t\t\t- Ted\n"},{"id":"49910","messageId":"85bqdm6jch.fsf@lola.goethe.zz","threadId":"9379","inReplyTo":"20070805154801.GD28263@thunk.org","subject":"Re: Terminology question about remote branches.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-05T16:23:42Z","receivedAt":"2007-08-05T16:23:42Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Theodore Tso writes:\n\n> To use a GNU emacs example, consider M-x customize, which is this\n> huge, very fancy, *very* complex hierarchical mechanism with a\n> pointy-clicky interface for setting options. Most emacs experts\n> wouldn't use it, preferring to open code raw emacs-lisp settings in\n> their .emacs.el. If you ask an old-time emacs user how to set up\n> some specific feature setting via M-x customize, they might look at\n> you blankly, because it's not an interface they use much, if at all.\n\nWell, let me throw you back one of your questions: do you have any\nstatistics backing this up?\n\nAs to anecdotal evidence: I am an old-time Emacs user, and I pretty\nmuch use customize _exclusively_ since it generally leaves me with a\n_working_ configuration even when the DOC string might be sub-optimal\nor misleading or hard to understand, and it makes sure that, say,\neverything to make a global minor mode _active_ (like loading some\nfile, or calling some initialization functions) is done at the right\npoint of time.\n\nIf \"old-time Emacs users\" would not use customize, why would pretty\nmuch _every_ package come with _working_ defcustoms? Who writes and\n_tests_ those defcustoms if not the \"old-time Emacs users\"?\n\n> A similar thing can be said of \"git branch\"; once you are familiar\n> with how git works at a conceptual level, it can often be\n> faster/easier to just hack the .git/config file directly, instead of\n> using \"git branch\" to set up things the way you want. And I'm\n> pretty sure there are ways to set up the config file when you edit\n> it by hand that you can't set up via \"git branch\".\n\nSure. But we don't want to _require_ this sort of special knowledge\nbefore one can even hope to do some basic task.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"49909","messageId":"86lkcqvtdx.fsf@blue.stonehenge.com","threadId":"9379","inReplyTo":"20070805154801.GD28263@thunk.org","subject":"Re: Terminology question about remote branches.","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-08-05T16:27:38Z","receivedAt":"2007-08-05T16:27:38Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Theodore\" == Theodore Tso writes:\n\nTheodore> To use a GNU emacs example, consider M-x customize, which is this\nTheodore> huge, very fancy, *very* complex hierarchical mechanism with a\nTheodore> pointy-clicky interface for setting options. Most emacs experts\nTheodore> wouldn't use it, preferring to open code raw emacs-lisp settings in\nTheodore> their .emacs.el. If you ask an old-time emacs user how to set up\nTheodore> some specific feature setting via M-x customize, they might look at\nTheodore> you blankly, because it's not an interface they use much, if at all.\n\nI beg to differ. I *am* an old-time Emacs user, and I resisted customize when\nit first appeared, because *most* of the things still didn't use it. However,\nas of a year ago, I assessed that customize had gotten to \"critical mass\", and\nthat 75% of my .emacs could be replaced by it. So I have, and it's made\nthings simpler for me.\n\nSo, it just has to be complete enough and flexible enough.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"49911","messageId":"20070805124050.c1345ec9.seanlkml@sympatico.ca","threadId":"9379","inReplyTo":"85fy2y89kb.fsf@lola.goethe.zz","subject":"Re: Terminology question about remote branches.","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-08-05T16:40:50Z","receivedAt":"2007-08-05T16:40:50Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 05 Aug 2007 14:12:04 +0200\nDavid Kastrup wrote:\n\n> Well, that is pretty much exactly what I find fascinating: that the\n> behavior is arbitrary and undocumented enough that one can't deduce it\n> either by logic or by recollection or by documentation, but just by\n> reading the code.\n> \n> Usually code is supposed to implement a design, but here it seems\n> rather like the design, if there is any, is to be abstracted from the\n> code.\n\nTo me it's yet another example of bad UI design in Git. Git already\nhad remote-tracking branches, which conceptually were relatively easy\nto explain. Instead of leveraging this foundation, and adding the\nability for local branches to pick a default remote-tracking branch\nto use for merging, Git instead implemented direct remote tracking\nfrom local branches. After having read the thread Jeff mentioned\nearlier i'm still at a loss as to how this decision was justified.\n\nTo make it even worse, it turns out that this command:\n\n $ git branch --track mybranch remote/branch\n\nDoes _NOT_ tell git to setup mybranch to track remote/branch. Read that\ncommand line again and then scratch your head as to how anyone without\ndeep Git knowledge is supposed to infer its real meaning without being\ntold to read previous email threads etc. This also means the feature\ncan't be used to say:\n\n $ git branch --track mybranch otherlocalbranch\n\nBeing a fan of Git, it's frustrating to see that more weight is not\npaid to such UI concerns. Especially when the concern _was_ raised\nwhen the feature was first added.\n\nSean\n"},{"id":"49912","messageId":"20070805164557.GA20721@coredump.intra.peff.net","threadId":"9379","inReplyTo":"20070805124050.c1345ec9.seanlkml@sympatico.ca","subject":"Re: Terminology question about remote branches.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-05T16:45:57Z","receivedAt":"2007-08-05T16:45:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 05, 2007 at 12:40:50PM -0400, Sean wrote:\n\n> To me it's yet another example of bad UI design in Git. Git already\n> had remote-tracking branches, which conceptually were relatively easy\n> to explain. Instead of leveraging this foundation, and adding the\n> ability for local branches to pick a default remote-tracking branch\n> to use for merging, Git instead implemented direct remote tracking\n> from local branches. After having read the thread Jeff mentioned\n> earlier i'm still at a loss as to how this decision was justified.\n\nTo be fair, the default remote-tracking branch stuff predates the thread\nI pointed you to. But I do agree it makes the system that much more\nconfusing to have it this way.\n\nThere is a clash between users with different workflows here, I think.\nFor example, I almost _never_ run git-pull, but instead always fetch,\ninspect, and then merge from a tracking branch. So I think of tracking\nbranches as a first-class item. But I suspect Linus doesn't use tracking\nbranches at all, since he pulls directly from a variety of different\nrepositories.\n\n-Peff\n"}]}