{"thread":{"id":"43197","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","startedAt":"2006-11-07T17:24:50Z","lastAt":"2006-11-08T17:36:22Z","messageCount":9,"participants":["Wink Saville","Shawn Pearce","Salikh Zakirov","Matthieu Moy","Andreas Ericsson","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296924","messageId":"20061107172450.GA26591@spearce.org","threadId":"43197","inReplyTo":null,"subject":"Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-07T17:24:50Z","receivedAt":"2006-11-07T17:24:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Today I was talking with someone that I collaborate with through\nGit and they still seemed to not get the idea that all branches\nin their repository are local, and that at least a 'git fetch'\nis needed to update the local tracking branches to the version\nin the central repository that we collaborate through.  And this\nisn't the first time we've had such discussions.\n\nIt dawned on me that this person still hasn't grasped the idea\nbehind fetch.  A few other users that I know also have commented on\nhow difficult fetch is to learn.\n\nMost seemed to think that fetch would update their working directory,\nor their current branch, as there is no other way to \"download\nchanges from origin\".  They also seem to expect their local tracking\nbranch to automatically update, especially when invoking\n`git checkout -b foo tracking-branch`.\n\n\nClearly there is a gap in communicating these ideas in a way that\nthey can be understood by users.  Of course in at least one case\nthe users just isn't reading any Git documentation and plows ahead\nas though it were CVS ('cause everything's \"just like CVS\") *sigh*.\n\n-- \n"},{"id":"295865","messageId":"eiqi3f$ouq$1@sea.gmane.org","threadId":"43197","inReplyTo":"20061107172450.GA26591@spearce.org","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Salikh Zakirov","fromEmail":"salikh.zakirov@intel.com","sentAt":"2006-11-07T18:08:47Z","receivedAt":"2006-11-07T18:08:47Z","isPatch":false,"sender":{"key":"salikh.zakirov@gmail.com","avatar":null},"body":"Shawn Pearce wrote:\n> Clearly there is a gap in communicating these ideas in a way that\n> they can be understood by users.  Of course in at least one case\n> the users just isn't reading any Git documentation and plows ahead\n> as though it were CVS ('cause everything's \"just like CVS\") *sigh*.\n\nI've went through persuading my colleagues (~30 engineers) to use Git and tutoring on it\nthrough the three summer months, and my experience is very similar to Shawn's.\n(i.e. confusing local and remote branches, not reading documentation,\nand \"just like CVS\" attitude)\n\nBelow is the one git feature that I think was stumbled upon most often:\n\n* people were often anaware of *multiple* branches created by git-clone,\n  as the operation they wanted was analog of \"cvs checkout\". \n\n* git-fetch / git-pull tries to download all of the branches that were\n  preset at git-clone time, and subsequently gives errors if some topic\n  branches were rewound or dropped, while most of the time my colleagues\n  were interested in just one \"mainline\" branch.\n\nI think that the particular issue with the workflow in my organization\ncould have been solved by the git-checkout and git-clone hybrid\n\n    git-checkout ssh://path.to/repo.git#branch [work_dir]\n\nwhich would clone repository with just one branch and setup the remotes\nfile accordingly (The syntax is completely made up, of course)\n\nP.S. a few words on the workflow we use:\n- there is a \"mainline\" branch of development, kept as ssh-shared git repository\n- mainline commits require some pre-commit testing, which takes ~1.5 hours,\n  so people tend not to commit to mainline too often. On average, a given\n  person commits to mainline once or twice a week.\n- mainlines commits also require a fellow developer review, that's where\n  topic branches come in handy. Topic branches are also useful for testing,\n  as pre-commit testing should be run on several different platforms, thus\n  on a different machines. Topic branches are kept on the same shared server.\n"},{"id":"296648","messageId":"vpqbqnisegc.fsf@ecrins.imag.fr","threadId":"43197","inReplyTo":"20061107172450.GA26591@spearce.org","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-11-08T05:19:15Z","receivedAt":"2006-11-08T05:19:15Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> Today I was talking with someone that I collaborate with through\n> Git and they still seemed to not get the idea that all branches\n> in their repository are local, and that at least a 'git fetch'\n> is needed to update the local tracking branches to the version\n> in the central repository that we collaborate through.  And this\n> isn't the first time we've had such discussions.\n\nTo me, the biggest difficulty was to understand the vocubulary. I\nstarted with cogito, and looked for branching features in cg-branch-*.\nThe /features/ themselves seem nice, but the names of commands are\nconfusing to me. I'd expect something called cg-branch-add to create a\nnew branch, while it just tells cogito where to find one. And the git\nVs cogito increased the confusion.\n\n-- \n"},{"id":"298433","messageId":"455169D1.8060408@saville.com","threadId":"43197","inReplyTo":"20061107172450.GA26591@spearce.org","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2006-11-08T05:23:29Z","receivedAt":"2006-11-08T05:23:29Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"As a newbie I'm confused, recently I attempted to get Andrew Morton's -mm \"tree\". It turns out the instructions were incorrect and Junio was kind enough to correct the mistake. But I for one am still confused.\n\n  git-fetch is; \"Download objects and a head from another repository\"\n\nFair enough and that make sense, but where does it go? Apparently it just gets stored in the object database and a reference to it in \"FETCH_HEAD\". Now what? Ok the documentation says:\n\n  'The information is left for a later merge operation done by \"git merge\"'\n\nNow in the case of fetching -mm apparently you don't do a merge, instead the instructions now read:\n\n  git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1\n  git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1\n\nThe git-fetch apparently gets \"linux-trees.git\" and places a reference to it in a tag named 'v2.6.16-rc2-mm1'. Then the git-checkout, check's out this tag to a new branch, there was no merge! This is confusing and makes no sense to this newbie.\n\nNow lets take a quick look at the git-merge documentation \"HOW MERGE WORKS\":\n\n\"A merge is always between the current HEAD and one or more remote branch heads, and the index file must exactly match the tree of HEAD commit (i.e. the contents of the last commit) when it happens. In other words, git-diff --cached HEAD must report no changes.\"\n\nSorry, there is basically no information in those two sentences that makes any sense to me. Take the first part, \"between the current HEAD and one or more remote branch heads\". So apparently merges occur against the current checkout branch, but I would guess the origin is also involved somehow? Secondly, what is the relationship between \"remote branch heads\" and FETCH_HEAD? I see no mention of FETCH_HEAD or how it might be used anywhere in the git-merge documentation.  Then we come to \"the index file must exactly match the tree HEAD commit\", sorry but my question is how could it not match? Obviously I don't understand how the index file is used, but I can say that adding \"git-diff --cached HEAD must report no no changes\" adds nothing to the explanation, yet I'm sure it does mean something to an expert.\n\nIt then goes onto say \"it may fetch the objects from remote\" I thought that is what \"fetch\" does.\n\nAnyway, as you can see there is room for confusion for some people.\n\nRegards,\n\n"},{"id":"295009","messageId":"20061108061020.GF28498@spearce.org","threadId":"43197","inReplyTo":"eiqi3f$ouq$1@sea.gmane.org","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-08T06:10:20Z","receivedAt":"2006-11-08T06:10:20Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Salikh Zakirov <Salikh.Zakirov@Intel.com> wrote:\n> I think that the particular issue with the workflow in my organization\n> could have been solved by the git-checkout and git-clone hybrid\n> \n>     git-checkout ssh://path.to/repo.git#branch [work_dir]\n> \n> which would clone repository with just one branch and setup the remotes\n> file accordingly (The syntax is completely made up, of course)\n\nRight; that would help us to but developers really want two mainline\nbranches locally (stable and slightly less stable) as they access\nthem frequently.\n\nHence the \"git clone --only a,b\" syntax that was floating around\non the mailing list the past few days.  Of course no implementation\nexists yet...\n \n> - there is a \"mainline\" branch of development, kept as ssh-shared git repository\n> - mainline commits require some pre-commit testing, which takes ~1.5 hours,\n>   so people tend not to commit to mainline too often. On average, a given\n>   person commits to mainline once or twice a week.\n> - mainlines commits also require a fellow developer review, that's where\n>   topic branches come in handy. Topic branches are also useful for testing,\n>   as pre-commit testing should be run on several different platforms, thus\n>   on a different machines. Topic branches are kept on the same shared server.\n\nPretty much the same workflow here; except that instead of a 1.5\nhour testing requirement to move code into the mainline we have a\nseveral day manual process where humans redo the changes that were\nalready made in git in the \"real\" SCM.\n\nUsually humans screw up redoing those changes and it takes a few more\ndays to figure out why a topic branch it Git that works correctly\nfails to even compile in the mainline.  So we don't push to the\nmainline often.\n\n-- \n"},{"id":"297628","messageId":"eis0v9$vug$1@sea.gmane.org","threadId":"43197","inReplyTo":"455169D1.8060408@saville.com","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-08T07:29:29Z","receivedAt":"2006-11-08T07:29:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Could you word-wrap your messages at some reasonable column, for example at\n72 or 76-columns wide?\n\nWink Saville wrote:\n\n> As a newbie I'm confused, recently I attempted to get Andrew Morton's\n> -mm \"tree\".\n\nWhich is unusual git usage, as Andrew Morton uses Quilt/his own patch tools,\nand not git, if I remember correctly.\n\n> It turns out the instructions were incorrect and Junio was \n> kind enough to correct the mistake. But I for one am still confused.  \n>\n>   git-fetch is; \"Download objects and a head from another repository\"\n> \n> Fair enough and that make sense, but where does it go? Apparently it just\n> gets stored in the object database and a reference to it in \"FETCH_HEAD\".\n> Now what? Ok the documentation says:  \n\nObjects gets stored into object database. Then (using FETCH_HEAD) heads\nof tracking branches gets updated (i.e. if there were some changes on\nbranch 'master' in remote, the objects are downloaded, then head of local\ntracking branch corresponding to remote branch 'master', e.g. 'origin',\ngets updated with the value in 'master'; so called fast-forward case).\n \n>   'The information is left for a later merge operation done by \"git\n>   merge\"' \n\nOr done by git pull. The information in FETCH_HEAD is for commit message\nin later merge (for example due to pull).\n \n> Now in the case of fetching -mm apparently you don't do a merge, instead\n> the instructions now read: \n> \n>   $ git-fetch \\\n>     git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git \\\n>     tag v2.6.16-rc2-mm1  \n>   $ git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1\n\nAre you sure that it is 'tag' there?\n\nBTW. you are actually encouraged to use \"git fetch\" and \"git checkout\",\nunless in scripts.\n\n> The git-fetch apparently gets \"linux-trees.git\" and places a reference to\n> it in a tag named 'v2.6.16-rc2-mm1'. Then the git-checkout, check's out\n> this tag to a new branch, there was no merge! This is confusing and makes\n> no sense to this newbie.   \n\nThe git-fetch fetches _from_ linux-trees.git repository. It fetches tag\nv2.6.16-rc2-mm1 (and its lineage, i.e. everything pointed by this tag,\ntransitively) and stores it as local tag v2.6.16-rc2-mm1. You cannot\ncheckout tag (you can't commit to tag), so you have to create new branch\nfor your changes (or for checkout).\n \n> Now lets take a quick look at the git-merge documentation \"HOW MERGE\n> WORKS\": \n> \n> \"A merge is always between the current HEAD and one or more remote branch\n> heads, and the index file must exactly match the tree of HEAD commit (i.e.\n> the contents of the last commit) when it happens. In other words, git-diff\n> --cached HEAD must report no changes.\"   \n\nThat's a bit untrue, because merge can happen between local branches too.\n \n> Sorry, there is basically no information in those two sentences that makes\n> any sense to me. Take the first part, \"between the current HEAD and one or\n> more remote branch heads\". So apparently merges occur against the current\n> checkout branch, but I would guess the origin is also involved somehow? \n\nCurrent HEAD is current checked out branch. You merge current HEAD and one\nor more [remote] branch heads (in the pull case, those not marked\nnot-for-merge in FETCH_HEAD), and place result in current branch.\n\n> Secondly, what is the relationship between \"remote branch heads\" and\n> FETCH_HEAD? I see no mention of FETCH_HEAD or how it might be used\n> anywhere in the git-merge documentation.\n\nFETCH_HEAD is low-lewel, not to be used by end-user (unless he/she wants to\ndo something unusual).\n\n> Then we come to \"the index file \n> must exactly match the tree HEAD commit\", sorry but my question is how\n> could it not match? \n\nFor example if you git-add'ed some files, but not committed the addition.\n\n> Obviously I don't understand how the index file is \n> used, but I can say that adding \"git-diff --cached HEAD must report no no\n> changes\" adds nothing to the explanation, yet I'm sure it does mean\n> something to an expert.          \n\nIt adds command which you can use to check _why_ merge failed to run.\n\n> It then goes onto say \"it may fetch the objects from remote\" I thought\n> that is what \"fetch\" does. \n\nIIRC this explanation is in git-pull(1). Pull in git is _fetch_ + merge.\n \n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296651","messageId":"4551CAF7.3050008@op5.se","threadId":"43197","inReplyTo":"vpqbqnisegc.fsf@ecrins.imag.fr","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-08T12:17:59Z","receivedAt":"2006-11-08T12:17:59Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n>> Today I was talking with someone that I collaborate with through\n>> Git and they still seemed to not get the idea that all branches\n>> in their repository are local, and that at least a 'git fetch'\n>> is needed to update the local tracking branches to the version\n>> in the central repository that we collaborate through.  And this\n>> isn't the first time we've had such discussions.\n> \n> To me, the biggest difficulty was to understand the vocubulary.\n\nI had that same problem, although I started with git and came from CVS / \nSVN. I am sufficiently experienced with those two system to hope that I \nwouldn't come across any similarities at all, so I wasn't expecting any, \nso I didn't get too badly bitten.\n\nThe Documentation/glossary.txt file is a very good place to start \nreading, although I wouldn't object to it being re-arranged to have the \nterms described there pop up \"in order of appearance\", so to speak. I \nsent in a couple of patches to the glossary file whenever I encountered \nsomething in gittish that I didn't understand. Sometimes I had managed \nto guess the correct meaning and the patch got applied. In other cases I \nhad it completely wrong and other, more gittish-fluent, people corrected \nthe patches and amended the documentation that led to the confusion.\n\nI think this is the only way to keep the docs alive and \nnewcomer-friendly. Sadly, neither the maintainer nor the active \ncontributors have newbie-eyes so we're relying on everyone who *are* new \nto git to help keep git easy for new people.\n\n\n> And the git Vs cogito increased the confusion.\n> \n\nI've found that too. It's a shame that some things can be done with git \nthat isn't possible (or at least easy) with cogito and the other way \naround. The shared but divergent terminology doesn't exactly help \neither. Now I fear it's too late to do anything about it.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\n"},{"id":"294017","messageId":"4552088D.6040709@saville.com","threadId":"43197","inReplyTo":"eis0v9$vug$1@sea.gmane.org","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2006-11-08T16:40:45Z","receivedAt":"2006-11-08T16:40:45Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"Jakub Narebski wrote:\n> Could you word-wrap your messages at some reasonable column, for example at\n> 72 or 76-columns wide?\n\ndone\n\n> Wink Saville wrote:\n> \n>> As a newbie I'm confused, recently I attempted to get Andrew Morton's\n>> -mm \"tree\".\n> \n> Which is unusual git usage, as Andrew Morton uses Quilt/his own patch tools,\n> and not git, if I remember correctly.\n> \n>> It turns out the instructions were incorrect and Junio was \n>> kind enough to correct the mistake. But I for one am still confused.  \n>>\n>>   git-fetch is; \"Download objects and a head from another repository\"\n>>\n>> Fair enough and that make sense, but where does it go? Apparently it just\n>> gets stored in the object database and a reference to it in \"FETCH_HEAD\".\n>> Now what? Ok the documentation says:  \n> \n> Objects gets stored into object database. Then (using FETCH_HEAD) heads\n> of tracking branches gets updated (i.e. if there were some changes on\n> branch 'master' in remote, the objects are downloaded, then head of local\n> tracking branch corresponding to remote branch 'master', e.g. 'origin',\n> gets updated with the value in 'master'; so called fast-forward case).\n>  \n\nOK, so fetch does more than just fetching, it also merges, confusing \nespecially given the that the Description says otherwise.\n\nI just searched git-fetch documentation and I see it mentioned under the \n<refspec> documentation. I read the words but why do I have to tell it \nwhat the source & destination. From my perspective the source is the url \nand the destination is my repository. So refspec doesn't make sense, of \ncourse it's my problem I'm not blaming git or the documentation. But as \na newbie I'm confused.\n\nAs I continue to investigate the <refspec> documentation it mentions in \nthe first \"Note\" that \".. rewound and rebased frequently, the a pull ..\" \n. OK, so why is \"pull\" mentioned here I'm not pulling I'm fetching. Of \ncourse if you go to the git-pull documentation we see the <refspec> \nrepeated. Which maybe isn't surprising since pull is a fetch+merge. So I \nguess the confusing part is that fetch does do merging, even though it \nsays it implies it doesn't.\n\n>>   'The information is left for a later merge operation done by \"git\n>>   merge\"' \n> \n> Or done by git pull. The information in FETCH_HEAD is for commit message\n> in later merge (for example due to pull).\n>  \n>> Now in the case of fetching -mm apparently you don't do a merge, instead\n>> the instructions now read: \n>>\n>>   $ git-fetch \\\n>>     git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git \\\n>>     tag v2.6.16-rc2-mm1  \n>>   $ git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1\n> \n> Are you sure that it is 'tag' there?\n> \n\nYes, this is directly from Junio.\n\n> BTW. you are actually encouraged to use \"git fetch\" and \"git checkout\",\n> unless in scripts.\n>\n>> The git-fetch apparently gets \"linux-trees.git\" and places a reference to\n>> it in a tag named 'v2.6.16-rc2-mm1'. Then the git-checkout, check's out\n>> this tag to a new branch, there was no merge! This is confusing and makes\n>> no sense to this newbie.   \n> \n> The git-fetch fetches _from_ linux-trees.git repository. It fetches tag\n> v2.6.16-rc2-mm1 (and its lineage, i.e. everything pointed by this tag,\n> transitively) and stores it as local tag v2.6.16-rc2-mm1. You cannot\n> checkout tag (you can't commit to tag), so you have to create new branch\n> for your changes (or for checkout).\n>  \n>> Now lets take a quick look at the git-merge documentation \"HOW MERGE\n>> WORKS\": \n>>\n>> \"A merge is always between the current HEAD and one or more remote branch\n>> heads, and the index file must exactly match the tree of HEAD commit (i.e.\n>> the contents of the last commit) when it happens. In other words, git-diff\n>> --cached HEAD must report no changes.\"   \n> \n> That's a bit untrue, because merge can happen between local branches too.\n>  \n>> Sorry, there is basically no information in those two sentences that makes\n>> any sense to me. Take the first part, \"between the current HEAD and one or\n>> more remote branch heads\". So apparently merges occur against the current\n>> checkout branch, but I would guess the origin is also involved somehow? \n> \n> Current HEAD is current checked out branch. You merge current HEAD and one\n> or more [remote] branch heads (in the pull case, those not marked\n> not-for-merge in FETCH_HEAD), and place result in current branch.\n> \n>> Secondly, what is the relationship between \"remote branch heads\" and\n>> FETCH_HEAD? I see no mention of FETCH_HEAD or how it might be used\n>> anywhere in the git-merge documentation.\n> \n> FETCH_HEAD is low-lewel, not to be used by end-user (unless he/she wants to\n> do something unusual).\n> \n\nThen why mention it at all?\n\n>> Then we come to \"the index file \n>> must exactly match the tree HEAD commit\", sorry but my question is how\n>> could it not match? \n> \n> For example if you git-add'ed some files, but not committed the addition.\n\nBut if I've added some files, it would seem perfectly reasonable that \ngit could still \"merge\" unless the new files conflicted with new files \nin the fetch.\n\n> \n>> Obviously I don't understand how the index file is \n>> used, but I can say that adding \"git-diff --cached HEAD must report no no\n>> changes\" adds nothing to the explanation, yet I'm sure it does mean\n>> something to an expert.          \n> \n> It adds command which you can use to check _why_ merge failed to run.\n> \n>> It then goes onto say \"it may fetch the objects from remote\" I thought\n>> that is what \"fetch\" does. \n> \n> IIRC this explanation is in git-pull(1). Pull in git is _fetch_ + merge.\n>  \n\nSo a source of confusion is fetch also does merging/fast-forwarding, \nthis is confusing. Fetch should fetch, merge should merge, pull should \ndo both.\n\nAnother source of confusion is we start out with two branches after \ncloning _master_ & _origin_. Now if I create my own branch and check it \nout and then do a pull, what is going to be merged where and when?\n\nI need to read, re-read and actually understand git-merge the \"Grand \nUnified Merge Driver\", I can see it's very powerful but with that power \ncomes confusion.\n\nAt the moment my current situation is that I've cloned 2.6.19 done some \npulls created some of my own branches and done a git-fetch on Andrew \nMorton's \"tree\". In .git/remotes I only have the file origin.\n\ngit-branch shows:\n\nwink@winkc2d1:~/linux/linux-2.6$ git-branch\n* ace\n   local-2.6.19-rc4-mm2\n   master\n   origin\n   w8\n\nIn tags I have:\n\nwink@winkc2d1:~/linux/linux-2.6$ ls .git/refs/tags\nace-0.0.1     v2.6.13-rc3  v2.6.15-rc1  v2.6.16-rc5  v2.6.18-rc3\nv2.6.11       v2.6.13-rc4  v2.6.15-rc2  v2.6.16-rc6  v2.6.18-rc4\nv2.6.11-tree  v2.6.13-rc5  v2.6.15-rc3  v2.6.17      v2.6.18-rc5\nv2.6.12       v2.6.13-rc6  v2.6.15-rc4  v2.6.17-rc1  v2.6.18-rc6\nv2.6.12-rc2   v2.6.13-rc7  v2.6.15-rc5  v2.6.17-rc2  v2.6.18-rc7\nv2.6.12-rc3   v2.6.14      v2.6.15-rc6  v2.6.17-rc3  v2.6.19-rc1\nv2.6.12-rc4   v2.6.14-rc1  v2.6.15-rc7  v2.6.17-rc4  v2.6.19-rc2\nv2.6.12-rc5   v2.6.14-rc2  v2.6.16      v2.6.17-rc5  v2.6.19-rc3\nv2.6.12-rc6   v2.6.14-rc3  v2.6.16-rc1  v2.6.17-rc6  v2.6.19-rc4\nv2.6.13       v2.6.14-rc4  v2.6.16-rc2  v2.6.18      v2.6.19-rc4-mm2\nv2.6.13-rc1   v2.6.14-rc5  v2.6.16-rc3  v2.6.18-rc1\nv2.6.13-rc2   v2.6.15      v2.6.16-rc4  v2.6.18-rc2\n\nIn remotes I have:\n\nwink@winkc2d1:~/linux/linux-2.6$ ls .git/remotes\norigin\n\nSo it would seem that I have no _remote_ connection to AM's tree and \nwhen I did the fetch it added objects which, from the perspective of \nlinus's tree, is just a branch that I could have created by hand.\n\nNow when I do my next git-pull from linu's tree what is going to happen \nwith regards to my various branches if we assume that *ace is currently \nchecked out.\n\nHere is the current state:\n\norigin\t\t\tunchanged\nmaster\t\t\tunchanged\nace\t\t\tlocally modified and currently checked out\nw8\t\t\tlocally modified\nlocal-2.6.19-rc4-mm2\tunchanged just a checkout of tag v2.6.19-rc4-mm2\n\nThanks,\n\nWink\n\n"},{"id":"298390","messageId":"200611081836.22779.jnareb@gmail.com","threadId":"43197","inReplyTo":"4552088D.6040709@saville.com","subject":"Re: Did anyone have trouble learning the idea of local vs. remote branches?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-08T17:36:22Z","receivedAt":"2006-11-08T17:36:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Please leave only the parts you are replying to when replying.\nThanks in advance.\n\nWink Saville wrote:\n> Jakub Narebski wrote:\n>> Wink Saville wrote:\n>> \n>>> It turns out the instructions were incorrect and Junio was \n>>> kind enough to correct the mistake. But I for one am still confused.  \n>>>\n>>>   git-fetch is; \"Download objects and a head from another repository\"\n>>>\n>>> Fair enough and that make sense, but where does it go? Apparently it just\n>>> gets stored in the object database and a reference to it in \"FETCH_HEAD\".\n>>> Now what? Ok the documentation says:  \n>> \n>> Objects gets stored into object database. Then (using FETCH_HEAD) heads\n>> of tracking branches gets updated (i.e. if there were some changes on\n>> branch 'master' in remote, the objects are downloaded, then head of local\n>> tracking branch corresponding to remote branch 'master', e.g. 'origin',\n>> gets updated with the value in 'master'; so called fast-forward case).\n>>  \n> \n> OK, so fetch does more than just fetching, it also merges, confusing \n> especially given the that the Description says otherwise.\n\nNo, git-fetch just (for each head/each branch) download the changes,\n_and_ updates head i.e. pointer to the downloaded changes. Without updating\nhead you wouldn't be able to access downloaded changes. git-fetch doesn't\ndo merge: it does only fast-forward.\n\nFor example, if you have on your branch 'next':\n\n  [local]   A---B---C <-- next\n\nand the repository you fetch from has few more commits:\n\n  [remote]  A---B---C---D---E <-- next\n\ngit-fetch downloads the objects (see that graoh for [local] is subgraph\nof graph for [remote] - this is fast-forward case)\n\n  [local]   A---B---C---D---E\n                    ^\n                    \\--- next\n\nand then updates next, but only in fast-forward case (the exception being\nthat you can demand fetch also for non-fast forward case)\n\n  [local]  A---B---C---D---E <-- next\n\n> I just searched git-fetch documentation and I see it mentioned under the \n> <refspec> documentation. I read the words but why do I have to tell it \n> what the source & destination. From my perspective the source is the url \n> and the destination is my repository. So refspec doesn't make sense, of \n> course it's my problem I'm not blaming git or the documentation. But as \n> a newbie I'm confused.\n\nThe confusion seems to descend from the fact, that there can be multiple\nbranches in git repository. When fetching, you must provide the URL to the\nrepository, which remote branches do you want to download, and what those\ntracking branches should be named in your repository. You can create shortcut\nname which contains all those info: the URL of repository and the <refspecs>,\ni.e. mapping from remote branches (which you want to download) names to the\nlocal branch names (what you want to save them as...) either as so called\n'remotes' file (file in .git/remotes) or, in latest version of git, in the\nrepository config. git-clone (or git-clone --use-separate-remotes)\ncreates remote file called 'origin', so you can use \"git fetch origin\" to\nfetch the changes made since the time you cloned the repository or fetched\nfrom it.\n \n> As I continue to investigate the <refspec> documentation it mentions in \n> the first \"Note\" that \".. rewound and rebased frequently, the a pull ..\" \n> . OK, so why is \"pull\" mentioned here I'm not pulling I'm fetching. Of \n> course if you go to the git-pull documentation we see the <refspec> \n> repeated. Which maybe isn't surprising since pull is a fetch+merge. So I \n> guess the confusing part is that fetch does do merging, even though it \n> says it implies it doesn't.\n\nAgain: fetch does not do merging. It's historical that the fetch refspecs\nare called \"Pull:\" lines.\n\n>>> Now in the case of fetching -mm apparently you don't do a merge, instead\n>>> the instructions now read: \n>>>\n>>>   $ git-fetch \\\n>>>     git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git \\\n>>>     tag v2.6.16-rc2-mm1  \n>>>   $ git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1\n>> \n>> Are you sure that it is 'tag' there?\n> \n> Yes, this is directly from Junio.\n\nOoops, I haven't read git-fetch(1) carefully enough:\n\n  Some short-cut notations are also supported.\n\n  * tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>;  it\n    requests fetching everything up to the given tag.\n\n>>> Secondly, what is the relationship between \"remote branch heads\" and\n>>> FETCH_HEAD? I see no mention of FETCH_HEAD or how it might be used\n>>> anywhere in the git-merge documentation.\n>> \n>> FETCH_HEAD is low-lewel, not to be used by end-user (unless he/she wants to\n>> do something unusual).\n> \n> Then why mention it at all?\n\nObsolete documentation? It's agreed that git-merge is neither fish nor fowl,\nneither plumbing (engine) command, nor truly porcelain (UI) command.\n\nYou should rather use git-pull, than run git-merge by hand. git-pull uses\ngit-merge, with FETCH_HEAD as one of arguments.\n \n>>> Then we come to \"the index file \n>>> must exactly match the tree HEAD commit\", sorry but my question is how\n>>> could it not match? \n>> \n>> For example if you git-add'ed some files, but not committed the addition.\n\nOr git-update-index some file, or you are in the middle of resolving\nmerge conflict, or you removed some files...\n \n> But if I've added some files, it would seem perfectly reasonable that \n> git could still \"merge\" unless the new files conflicted with new files \n> in the fetch.\n\nIn which case it would be too late. Git detects possibility of conflict\n(not clean index), and aborts early.\n\n>>> It then goes onto say \"it may fetch the objects from remote\" I thought\n>>> that is what \"fetch\" does. \n>> \n>> IIRC this explanation is in git-pull(1). Pull in git is _fetch_ + merge.\n>>  \n> \n> So a source of confusion is fetch also does merging/fast-forwarding, \n> this is confusing. Fetch should fetch, merge should merge, pull should \n> do both.\n\nFetch without updating refs would mean no access to downloaded objects.\nRefs updating happend only (unless forced) in fast-forward case, i.e.\nin the case of merge which is not a merge.\n\n> Another source of confusion is we start out with two branches after \n> cloning _master_ & _origin_. Now if I create my own branch and check it \n> out and then do a pull, what is going to be merged where and when?\n\nUse --use-separate-remotes if master/origin confuses you. In short:\n \nwithout --use-separate-remotes:\n\n   local branch    | remote branch   | can commit  | should commit\n   ----------------------------------------------------------------\n   master          | ----            | Yes         | Yes\n   origin          | master          | Yes         | No\n   next            | next            | Yes         | No\n\nMaster branch is for _your_ work. When you are on master branch, and do\n'git pull', git does fetching and the merges _topmost_ branch in remotes\nfile ('origin') into current branch ('master').\n\nwith --use-separate-remotes\n\n   local branch          | remote branch | can commit | should commit\n   ------------------------------------------------------------------\n   master                | ----          | Yes        | Yes\n   remotes/origin/master | master        | No         | No\n   remotes/origin/next   | next          | No         | No\n\n> I need to read, re-read and actually understand git-merge the \"Grand \n> Unified Merge Driver\", I can see it's very powerful but with that power \n> comes confusion.\n\nDon't use git-merge. Use git-pull. If you want merge local branches, use\n'.' as the name of repository (means here: local repository).\n \nYes, this is confusing. Historical reasons, most probably.\n\n[...]\n-- \nJakub Narebski\n"}]}