{"thread":{"id":"13890","subject":"\"git pull . \" versus \"git merge \"","startedAt":"2008-06-11T00:51:00Z","lastAt":"2008-06-12T01:00:34Z","messageCount":16,"participants":["Rene Herman","David Symonds","Miklos Vajna","Paolo Bonzini","Daniel Barkalow","Brandon Casey","Mikael Magnusson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"79408","messageId":"484F2174.9020508@keyaccess.nl","threadId":"13890","inReplyTo":null,"subject":"\"git pull . \" versus \"git merge \"","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-06-11T00:51:00Z","receivedAt":"2008-06-11T00:51:00Z","isPatch":false,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"Good day.\n\nThe manpages seem to be making somewhat of a point of mentioning \"git \npull . \" as the way to merge a local branch into the current one \nbut a simple \"git merge \" seems to work well. Is there a difference?\n\nRene.\n"},{"id":"79410","messageId":"ee77f5c20806101806u6dc04152rb8307eb12a6167c@mail.gmail.com","threadId":"13890","inReplyTo":"484F2174.9020508@keyaccess.nl","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-06-11T01:06:32Z","receivedAt":"2008-06-11T01:06:32Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Wed, Jun 11, 2008 at 10:51 AM, Rene Herman wrote:\n\n> The manpages seem to be making somewhat of a point of mentioning \"git pull .\n> \" as the way to merge a local branch into the current one but a\n> simple \"git merge \" seems to work well. Is there a difference?\n\ngit pull also does a fetch in it's usual mode of operation, and runs\ngit merge to do merge changes in the remote-tracking branches.\n\n\nDave.\n"},{"id":"79411","messageId":"484F26C9.9080608@keyaccess.nl","threadId":"13890","inReplyTo":"ee77f5c20806101806u6dc04152rb8307eb12a6167c@mail.gmail.com","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-06-11T01:13:45Z","receivedAt":"2008-06-11T01:13:45Z","isPatch":false,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 11-06-08 03:06, David Symonds wrote:\n> On Wed, Jun 11, 2008 at 10:51 AM, Rene Herman wrote:\n> \n>> The manpages seem to be making somewhat of a point of mentioning \"git pull .\n>> \" as the way to merge a local branch into the current one but a\n>> simple \"git merge \" seems to work well. Is there a difference?\n> \n> git pull also does a fetch in it's usual mode of operation, and runs\n> git merge to do merge changes in the remote-tracking branches.\n\nSo in the case of merging a branch from the local repository into the \ncurrent branch, there is no difference between the two?\n\nRene.\n"},{"id":"79417","messageId":"20080611015608.GD29404@genesis.frugalware.org","threadId":"13890","inReplyTo":"484F26C9.9080608@keyaccess.nl","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-06-11T01:56:08Z","receivedAt":"2008-06-11T01:56:08Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Jun 11, 2008 at 03:13:45AM +0200, Rene Herman wrote:\n> So in the case of merging a branch from the local repository into the \n> current branch, there is no difference between the two?\n\nThere is no difference, but you really want to use git merge and not git\npull in such a case, I guess the git pull form is supported mainly to\nkeep backwards compatibility.\n"},{"id":"79418","messageId":"484F3200.2090800@keyaccess.nl","threadId":"13890","inReplyTo":"20080611015608.GD29404@genesis.frugalware.org","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-06-11T02:01:36Z","receivedAt":"2008-06-11T02:01:36Z","isPatch":false,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 11-06-08 03:56, Miklos Vajna wrote:\n\n> On Wed, Jun 11, 2008 at 03:13:45AM +0200, Rene Herman\n> wrote:\n\n>> So in the case of merging a branch from the local repository into\n>> the current branch, there is no difference between the two?\n> \n> There is no difference, but you really want to use git merge and not\n> git pull in such a case, I guess the git pull form is supported\n> mainly to keep backwards compatibility.\n\nThanks much, nice and clear! It might be good to adjust the git-pull \nmanpage a bit if the merge is preferred? It sorts of sounds like its \nadvertising the pull method now.\n\nRegards,\nRene\n"},{"id":"79419","messageId":"484F32B1.4050506@gnu.org","threadId":"13890","inReplyTo":"20080611015608.GD29404@genesis.frugalware.org","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-11T02:04:33Z","receivedAt":"2008-06-11T02:04:33Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Miklos Vajna wrote:\n> On Wed, Jun 11, 2008 at 03:13:45AM +0200, Rene Herman wrote:\n>> So in the case of merging a branch from the local repository into the \n>> current branch, there is no difference between the two?\n> \n> There is no difference, but you really want to use git merge and not git\n> pull in such a case, I guess the git pull form is supported mainly to\n> keep backwards compatibility.\n\nHowever, when you're on a tracking merge only \"git pull\" will merge the \nright branch automatically into the current branch, fetching the branch \nname to merge from the config. If the branch.*.remote config key is \n\".\", it will do a local merge.\n\nNote that \"git pull .\" is optimized in that the fetch does nothing \nexcept setting up MERGE_HEAD.\n\nPaolo\n"},{"id":"79422","messageId":"484F33E9.1060205@keyaccess.nl","threadId":"13890","inReplyTo":"484F32B1.4050506@gnu.org","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-06-11T02:09:45Z","receivedAt":"2008-06-11T02:09:45Z","isPatch":false,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 11-06-08 04:04, Paolo Bonzini wrote:\n> Miklos Vajna wrote:\n>> On Wed, Jun 11, 2008 at 03:13:45AM +0200, Rene Herman \n>> wrote:\n>>> So in the case of merging a branch from the local repository into the \n>>> current branch, there is no difference between the two?\n>>\n>> There is no difference, but you really want to use git merge and not git\n>> pull in such a case, I guess the git pull form is supported mainly to\n>> keep backwards compatibility.\n> \n> However, when you're on a tracking merge\n\nOn a what? :)\n\n> only \"git pull\" will merge the right branch automatically into the\n> current branch, fetching the branch name to merge from the config.\n> If the branch.*.remote config key is \".\", it will do a local merge.\n> \n> Note that \"git pull .\" is optimized in that the fetch does nothing \n> except setting up MERGE_HEAD.\n\nRene.\n"},{"id":"79429","messageId":"484F6162.6060606@gnu.org","threadId":"13890","inReplyTo":"484F33E9.1060205@keyaccess.nl","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-06-11T05:23:46Z","receivedAt":"2008-06-11T05:23:46Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>>> There is no difference, but you really want to use git merge and not git\n>>> pull in such a case, I guess the git pull form is supported mainly to\n>>> keep backwards compatibility.\n>>\n>> However, when you're on a tracking merge\n> \n> On a what? :)\n\nTracking *branch*, sorry. A branch that has configuration options like\n\n\t[branch \"foo\"]\n\t\tremote = origin\n\t\tmerge = next\n\nso that git knows that, when you're on branch foo, \"git pull\" is \nactually equivalent to \"git pull origin next:foo\".\n\nPaolo\n"},{"id":"79470","messageId":"alpine.LNX.1.00.0806111340570.19665@iabervon.org","threadId":"13890","inReplyTo":"484F2174.9020508@keyaccess.nl","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-11T17:56:41Z","receivedAt":"2008-06-11T17:56:41Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 Jun 2008, Rene Herman wrote:\n\n> Good day.\n> \n> The manpages seem to be making somewhat of a point of mentioning \"git pull .\n> \" as the way to merge a local branch into the current one but a simple\n> \"git merge \" seems to work well. Is there a difference?\n\nThose manpage sections predate the existance of \"git merge \". If \nyou're not planning to use git before November 2006, there's no reason to \nuse the \"git pull .\" form. They should probably be replaced with more \nhelpful examples at this point.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"79474","messageId":"XZoDb2arIiMts-bX6jjK15wC9cOn5lPGgCOQYbY9YIyNm_nfcDf5gQ@cipher.nrlssc.navy.mil","threadId":"13890","inReplyTo":"alpine.LNX.1.00.0806111340570.19665@iabervon.org","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-11T18:32:21Z","receivedAt":"2008-06-11T18:32:21Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Daniel Barkalow wrote:\n> On Wed, 11 Jun 2008, Rene Herman wrote:\n> \n>> Good day.\n>>\n>> The manpages seem to be making somewhat of a point of mentioning \"git pull .\n>> \" as the way to merge a local branch into the current one but a simple\n>> \"git merge \" seems to work well. Is there a difference?\n> \n> Those manpage sections predate the existance of \"git merge \". If \n> you're not planning to use git before November 2006, there's no reason to \n> use the \"git pull .\" form. They should probably be replaced with more \n> helpful examples at this point.\n\nWas there some past discussion of the ui merits of a separate 'merge' command\nfor dealing with local merges and a 'pull' command for remote merges? I\nunderstand merge is the backend. The question has to do with the high-level\nuser interface: one command or two? Why wasn't git-pull enough?\n\nI ask because elsewhere in this thread Miklos suggests that git-merge should\nbe preferred over git-pull when dealing with a local repostory and you suggest\nhere that the documentation should be updated to use the 'git merge' method\ninstead of 'git pull'. I had the impression that git-merge was only used by\nthose who had not yet gotten their mind around the pull methodology. So it\nwas more of an 'ease the transition from other SCMs' rather than the recommended\nway of doing things.\n\n-brandon\n"},{"id":"79485","messageId":"alpine.LNX.1.00.0806111513380.19665@iabervon.org","threadId":"13890","inReplyTo":"XZoDb2arIiMts-bX6jjK15wC9cOn5lPGgCOQYbY9YIyNm_nfcDf5gQ@cipher.nrlssc.navy.mil","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-11T19:46:31Z","receivedAt":"2008-06-11T19:46:31Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 Jun 2008, Brandon Casey wrote:\n\n> Daniel Barkalow wrote:\n> > On Wed, 11 Jun 2008, Rene Herman wrote:\n> > \n> >> Good day.\n> >>\n> >> The manpages seem to be making somewhat of a point of mentioning \"git pull .\n> >> \" as the way to merge a local branch into the current one but a simple\n> >> \"git merge \" seems to work well. Is there a difference?\n> > \n> > Those manpage sections predate the existance of \"git merge \". If \n> > you're not planning to use git before November 2006, there's no reason to \n> > use the \"git pull .\" form. They should probably be replaced with more \n> > helpful examples at this point.\n> \n> Was there some past discussion of the ui merits of a separate 'merge' command\n> for dealing with local merges and a 'pull' command for remote merges? I\n> understand merge is the backend. The question has to do with the high-level\n> user interface: one command or two? Why wasn't git-pull enough?\n\n\"git pull . \" does \"git fetch . \" and then merges it. Of \ncourse, \"git fetch . \" does nothing at all, and it's weird as a \nuser interface to have the only (simple) way of selecting something to \nmerge be to fetch it as if from a remote repository, but from the local \nrepository. After all, no other purely local operation requires you to \nfirst fetch the thing you're interesting in from yourself.\n\n> I ask because elsewhere in this thread Miklos suggests that git-merge should\n> be preferred over git-pull when dealing with a local repostory and you suggest\n> here that the documentation should be updated to use the 'git merge' method\n> instead of 'git pull'. I had the impression that git-merge was only used by\n> those who had not yet gotten their mind around the pull methodology. So it\n> was more of an 'ease the transition from other SCMs' rather than the recommended\n> way of doing things.\n\nI think everybody uses \"git merge\" instead of \"git pull .\" these days. \nIt's shorter and less fiddly to type, and doesn't polute your bash reverse \nsearch for \"git pull\" with local things. And, if you've got a bunch \nof local branches, which is not uncommon and very much native to git, the \nintuitive thing is to merge them with \"git merge\" instead of treating them \nas if they weren't local.\n\nIt's also now pretty common to want to do \"git fetch \", inspect \nit, decide whether this is something you want to merge (and depend on), \nand do \"git merge \" to include it in your branch if you want it. \n(And being able to fetch stuff from a remote location, and later do a \nmerge without any non-local information is also very git-style.)\n\nOf course, if you're pulling from a remote repository, you generally want \nto use \"git pull\", but you wouldn't be using \"git pull .\"\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"79503","messageId":"kpNEshc02wSu18FDnzOIvMAjQu_lmbk4tK_T_9HGh38@cipher.nrlssc.navy.mil","threadId":"13890","inReplyTo":"alpine.LNX.1.00.0806111513380.19665@iabervon.org","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-11T21:01:57Z","receivedAt":"2008-06-11T21:01:57Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Daniel Barkalow wrote:\n> On Wed, 11 Jun 2008, Brandon Casey wrote:\n> \n>> Daniel Barkalow wrote:\n>>> On Wed, 11 Jun 2008, Rene Herman wrote:\n>>>\n>>>> Good day.\n>>>>\n>>>> The manpages seem to be making somewhat of a point of mentioning \"git pull .\n>>>> \" as the way to merge a local branch into the current one but a simple\n>>>> \"git merge \" seems to work well. Is there a difference?\n>>> Those manpage sections predate the existance of \"git merge \". If \n>>> you're not planning to use git before November 2006, there's no reason to \n>>> use the \"git pull .\" form. They should probably be replaced with more \n>>> helpful examples at this point.\n>> Was there some past discussion of the ui merits of a separate 'merge' command\n>> for dealing with local merges and a 'pull' command for remote merges? I\n>> understand merge is the backend. The question has to do with the high-level\n>> user interface: one command or two? Why wasn't git-pull enough?\n> \n> \"git pull . \" does \"git fetch . \" and then merges it. Of \n> course, \"git fetch . \" does nothing at all, and it's weird as a \n> user interface to have the only (simple) way of selecting something to \n> merge be to fetch it as if from a remote repository, but from the local \n> repository. After all, no other purely local operation requires you to \n> first fetch the thing you're interesting in from yourself.\n\nI don't agree with this paragraph. I think it _would_ be weird if you had\nto type 'git fetch' and then 'git merge' (or git pull) when operating on\na local repository, but that is not necessary. It is only necessary to\ntype 'git pull'. There is symmetry between operating on a remote repository\nand operating on a local repository. The user does not need to know that\na noop fetch is first performed, or whether the pull command detects that\nit is operating on a local repository and just skips the fetch, any more than\nthe user is required to know the exact sequence of events that allows an ssh\nsession to succeed.\n\n>> I ask because elsewhere in this thread Miklos suggests that git-merge should\n>> be preferred over git-pull when dealing with a local repostory and you suggest\n>> here that the documentation should be updated to use the 'git merge' method\n>> instead of 'git pull'. I had the impression that git-merge was only used by\n>> those who had not yet gotten their mind around the pull methodology. So it\n>> was more of an 'ease the transition from other SCMs' rather than the recommended\n>> way of doing things.\n> \n> I think everybody uses \"git merge\" instead of \"git pull .\" these days. \n> It's shorter and less fiddly to type, and doesn't polute your bash reverse \n> search for \"git pull\" with local things. And, if you've got a bunch \n> of local branches, which is not uncommon and very much native to git, the \n> intuitive thing is to merge them with \"git merge\" instead of treating them \n> as if they weren't local.\n\nNot sure about this one either. I think git-merge is intuitive to those who are\nfamiliar with the operation of git-pull, specifically those that understand how\nto use git-fetch and that git-pull does a fetch and then a merge. For those new\nto git, I think git-fetch takes a little while to get a handle on.\n\ngit-pull allows treating all branches as equal for merging purposes. A user does\nnot have to differentiate between a local and a remote branch by using different\ncommands. So I did not see it as 'treating [a local branch] as if they weren't local',\nbut instead as a single command to merge branches regardless of whether they are\nlocal or remote.\n\nSuggesting git-merge is what requires the user to make a distinction between local\nand remote branches.\n\n> It's also now pretty common to want to do \"git fetch \", inspect \n> it, decide whether this is something you want to merge (and depend on), \n> and do \"git merge \" to include it in your branch if you want it. \n> (And being able to fetch stuff from a remote location, and later do a \n> merge without any non-local information is also very git-style.)\n\nYes, I agree that it is common to fetch and inspect before merging. The\n'git merge ' could have been 'git pull . ', which only\nrequires typing one additional character. The user _must_ know how to use\ngit-pull, and the concept of '.' as a placeholder for the local repository\ntakes only a moment to digest. git-merge is an additional command that the\nuser must know when to use and when not to use. Well maybe that exaggerates\nthe point a little, git-merge is not that complicated, but it is an additional\ncommand to learn with little benefit that I see.\n\nTo summarize my point, I think the recommended advertised merge command could\nbe one single command 'git-pull' and that it should be used in the documentation\nin preference to 'git-merge'. It seems to me that this simplifies the user\ninterface and requires the user to master fewer commands before becoming productive.\n\nAlso, I thought this was already the status-quo and so I have been surprised by the\nincreasing suggestions to use git-merge on the mailing list. I saw it as something\nsimilar to suggestions I've seen to use git-reflog (not porcelain) rather than\n'git-log -g' (porcelain).\n\n-brandon\n"},{"id":"79512","messageId":"237967ef0806111449i7d23976dxa3290eece06b5876@mail.gmail.com","threadId":"13890","inReplyTo":"kpNEshc02wSu18FDnzOIvMAjQu_lmbk4tK_T_9HGh38@cipher.nrlssc.navy.mil","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2008-06-11T21:49:49Z","receivedAt":"2008-06-11T21:49:49Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2008/6/11 Brandon Casey :\n> Daniel Barkalow wrote:\n>> On Wed, 11 Jun 2008, Brandon Casey wrote:\n>>\n>>> Daniel Barkalow wrote:\n>>>> On Wed, 11 Jun 2008, Rene Herman wrote:\n>>>>\n>>>>> Good day.\n>>>>>\n>>>>> The manpages seem to be making somewhat of a point of mentioning \"git pull .\n>>>>> \" as the way to merge a local branch into the current one but a simple\n>>>>> \"git merge \" seems to work well. Is there a difference?\n>>>> Those manpage sections predate the existance of \"git merge \". If\n>>>> you're not planning to use git before November 2006, there's no reason to\n>>>> use the \"git pull .\" form. They should probably be replaced with more\n>>>> helpful examples at this point.\n>>> Was there some past discussion of the ui merits of a separate 'merge' command\n>>> for dealing with local merges and a 'pull' command for remote merges? I\n>>> understand merge is the backend. The question has to do with the high-level\n>>> user interface: one command or two? Why wasn't git-pull enough?\n>>\n>> \"git pull . \" does \"git fetch . \" and then merges it. Of\n>> course, \"git fetch . \" does nothing at all, and it's weird as a\n>> user interface to have the only (simple) way of selecting something to\n>> merge be to fetch it as if from a remote repository, but from the local\n>> repository. After all, no other purely local operation requires you to\n>> first fetch the thing you're interesting in from yourself.\n>\n> I don't agree with this paragraph. I think it _would_ be weird if you had\n> to type 'git fetch' and then 'git merge' (or git pull) when operating on\n> a local repository, but that is not necessary. It is only necessary to\n> type 'git pull'. There is symmetry between operating on a remote repository\n> and operating on a local repository. The user does not need to know that\n> a noop fetch is first performed, or whether the pull command detects that\n> it is operating on a local repository and just skips the fetch, any more than\n> the user is required to know the exact sequence of events that allows an ssh\n> session to succeed.\n\n> The user _must_ know how to use git-pull\n\nI've used git for a couple of months, and I've never used git-pull, only fetch\nand merge. To me it doesn't make any sense that you would want to merge changes\nwithout looking at them first. It also seems very strange to me to treat\nnot-yet-fetched branches on a remote the same as a local branch. I don't really\nhave any useful input other than that you shouldn't assume what other people\nfind intuitive, because you are usually wrong :).\n\n> Well maybe that exaggerates the point a little, git-merge is not that complicated,\n> but it is an additional command to learn with little benefit that I see.\n\nFor me, git-pull is that additional command, and using git-pull .\n to merge\nfeels really really strange. Why would I pull something I already have?\n\n> I saw it as something similar to suggestions I've seen to use git-reflog\n> (not porcelain) rather than 'git-log -g' (porcelain).\n\nThe output of git-reflog is easier to read when you know what you're\nlooking for,\nthe actual commit message and author info that log outputs is usually\nsuperfluous.\n\n-- \nMikael Magnusson\n"},{"id":"79519","messageId":"7v3anjbmov.fsf@gitster.siamese.dyndns.org","threadId":"13890","inReplyTo":"484F2174.9020508@keyaccess.nl","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-11T23:01:52Z","receivedAt":"2008-06-11T23:01:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rene Herman writes:\n\n> Good day.\n>\n> The manpages seem to be making somewhat of a point of mentioning \"git\n> pull . \" as the way to merge a local branch into the current\n> one but a simple \"git merge \" seems to work well. Is there a\n> difference?\n\nThere isn't any.\n\n\"git pull . this_branch\" is just a natural and logical consequence that\nyou can fetch and merge a branch B from remote U with \"git pull $U $B\".\n\n\"git merge that_branch\" exists and useful because people on average merge\nlocal branches more than they fetch and merge from remote repository.\n"},{"id":"79530","messageId":"48507454.2070506@keyaccess.nl","threadId":"13890","inReplyTo":"237967ef0806111449i7d23976dxa3290eece06b5876@mail.gmail.com","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-06-12T00:56:52Z","receivedAt":"2008-06-12T00:56:52Z","isPatch":false,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 11-06-08 23:49, Mikael Magnusson wrote:\n\n> For me, git-pull is that additional command, and using git-pull . \n> to merge feels really really strange. Why would I pull\n> something I already have?\n\nFor what it's worth I (as thread starter) agree with this. At least in \nmy mind local and remote branches are very different and I do not mind \nhaving to \"fetch\" the latter first before merging (nor combine the two \nthrough a \"pull\").\n\nI can see the reason for the other viewpoint as well since it emphasises \na point about local and remote branches _not_ being very different after \nall but that's more a symmetry to the implementor than it is to a user I \nfeel. For the user, local and remote branches just are different.\n\nAnd as such I feel it actually helps to just use \"merge\". Thanks for the \nanswers everyone -- this was a matter of a user worrying that he wasn't \ngetting it...\n\nRene\n"},{"id":"79531","messageId":"48507532.3030007@keyaccess.nl","threadId":"13890","inReplyTo":"7v3anjbmov.fsf@gitster.siamese.dyndns.org","subject":"Re: \"git pull . \" versus \"git merge \"","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-06-12T01:00:34Z","receivedAt":"2008-06-12T01:00:34Z","isPatch":false,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 12-06-08 01:01, Junio C Hamano wrote:\n\n> Rene Herman writes:\n\n>> The manpages seem to be making somewhat of a point of mentioning \"git\n>> pull . \" as the way to merge a local branch into the current\n>> one but a simple \"git merge \" seems to work well. Is there a\n>> difference?\n> \n> There isn't any.\n> \n> \"git pull . this_branch\" is just a natural and logical consequence that\n> you can fetch and merge a branch B from remote U with \"git pull $U $B\".\n> \n> \"git merge that_branch\" exists and useful because people on average merge\n> local branches more than they fetch and merge from remote repository.\n\nThank you. Slowly getting more comfortable with git...\n\nRene.\n"}]}