{"thread":{"id":"5639","subject":"Git user survey and `git pull`","startedAt":"2006-09-21T16:24:01Z","lastAt":"2006-09-23T14:12:00Z","messageCount":16,"participants":["Shawn Pearce","Petr Baudis","Nicolas Pitre","Johannes Schindelin","Jakub Narebski","Linus Torvalds","Junio C Hamano","Santi","Matthias Urlichs","Alan Chandler"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27368","messageId":"20060921162401.GD3934@spearce.org","threadId":"5639","inReplyTo":null,"subject":"Git user survey and `git pull`","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-21T16:24:01Z","receivedAt":"2006-09-21T16:24:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"I just saw this comment under question 20:\n\n git-pull's behavior of merging in the first refspec to the\n current branch is very bad and has caused us serious repository\n issues in xorg.\n\nMost of the folks I've been teaching Git to recently have found `git\nfetch` to be a very counterintuitive command for fetching things.\nEspecially since `git push` is what's used to send changes to\nthe remote repository. They also find `git pull . foo` as a\ncounterintuitive way to merge changes.\n\nBasically I'm seeing users run `git pull` when they probably\nshould have run just `git fetch`; the pull obviously also merges\nthe first refspec in .git/remotes/origin to the current branch\nand that's usually not what the user wanted, especially when the\nupstream remote has several branches that the user may be tracking\n(e.g. stable, dev, experimental).\n\n\nI think its probably too late to change the UI[*1*] but I think\nit is definately an issue for folks learning Git. Calling push\npush, fetch fetch and fetch+merge pull is probably a design flaw.\nIMHO it probably should have been something like:\n\n Current Shoulda Been\n --------------- ----------------\n git-push git-push\n git-fetch git-pull\n git-pull . foo git-merge foo\n git-pull git-pull --merge\n git-merge git-merge-driver\n\nin other words pull does the download and doesn't automatically\nstart a merge unless --merge was also given and git-merge is a\ncleaner wrapper around the Grand Unified Merge Driver that makes\nit easier to start a merge.\n\n\n[*1*] I bet a lot of scripts are currently based on the core\n Git Poreclain level functions. I try to avoid them myself\n in scripts and go right to the plumbing but not everyone\n does that.\n\n-- \nShawn.\n"},{"id":"27372","messageId":"20060921164048.GY8259@pasky.or.cz","threadId":"5639","inReplyTo":"20060921162401.GD3934@spearce.org","subject":"Re: Git user survey and `git pull`","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-21T16:40:48Z","receivedAt":"2006-09-21T16:40:48Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 21, 2006 at 06:24:01PM CEST, I got a letter\nwhere Shawn Pearce said that...\n> in other words pull does the download and doesn't automatically\n> start a merge\n\nThis is artifact of the BitKeeper terminology. This is the meaning in\nmost other VCSes but in BitKeeper, pull meant \"get changes and merge\nthem\", not just \"get changes\". So the BitKeeper legacy lives on. :-)\n\nThe route I took for Cogito is to just avoid calling _any_ command\n\"pull\". It's too confusing. \"update\" does the same as \"cvs update\" or\n\"svn update\" and I didn't notice people having much problem with that.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i I think its probably too late to change the UI[*1*] but I think\n> it is definately an issue for folks learning Git. Calling push\n> push, fetch fetch and fetch+merge pull is probably a design flaw.\n> IMHO it probably should have been something like:\n> \n> Current Shoulda Been\n> --------------- ----------------\n> git-push git-push\n> git-fetch git-pull\n> git-pull . foo git-merge foo\n> git-pull git-pull --merge\n> git-merge git-merge-driver\n> \n> in other words pull does the download and doesn't automatically\n> start a merge unless --merge was also given and git-merge is a\n> cleaner wrapper around the Grand Unified Merge Driver that makes\n> it easier to start a merge.\n\nI must say that I second this. Although I'm rather familiar with GIT I \nstill feel unconfortable with the current naming and behavior.\n\n\nNicolas\n"},{"id":"27379","messageId":"20060921170922.GA4375@spearce.org","threadId":"5639","inReplyTo":"Pine.LNX.4.64.0609211259340.2627@xanadu.home","subject":"Re: Git user survey and `git pull`","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-21T17:09:22Z","receivedAt":"2006-09-21T17:09:22Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> On Thu, 21 Sep 2006, Shawn Pearce wrote:\n> > Current Shoulda Been\n> > --------------- ----------------\n> > git-push git-push\n> > git-fetch git-pull\n> > git-pull . foo git-merge foo\n> > git-pull git-pull --merge\n> > git-merge git-merge-driver\n> > \n> > in other words pull does the download and doesn't automatically\n> > start a merge unless --merge was also given and git-merge is a\n> > cleaner wrapper around the Grand Unified Merge Driver that makes\n> > it easier to start a merge.\n> \n> I must say that I second this. Although I'm rather familiar with GIT I \n> still feel unconfortable with the current naming and behavior.\n\nThe only way I've been able to resolve it internally is to say:\n\n ``I can pull the changes contained in branch foo into\n\t my current working branch by `git pull . foo`. I'm\n\t not merging changes, I'm pulling them.``\n\nUh, yea....\n\nAs a prior user of a popular VCS which was also used by some folks\non LKML and which also had a 'pull=fetch+merge' command I fully\nunderstand why its pull in Git - but I don't like it.\n\n-- \nShawn.\n"},{"id":"27380","messageId":"Pine.LNX.4.63.0609211908580.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5639","inReplyTo":"Pine.LNX.4.64.0609211259340.2627@xanadu.home","subject":"Re: Git user survey and `git pull`","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-21T17:12:34Z","receivedAt":"2006-09-21T17:12:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 21 Sep 2006, Nicolas Pitre wrote:\n\n> On Thu, 21 Sep 2006, Shawn Pearce wrote:\n> \n> > I think its probably too late to change the UI[*1*] but I think\n> > it is definately an issue for folks learning Git. Calling push\n> > push, fetch fetch and fetch+merge pull is probably a design flaw.\n> > IMHO it probably should have been something like:\n> > \n> > Current Shoulda Been\n> > --------------- ----------------\n> > git-push git-push\n> > git-fetch git-pull\n> > git-pull . foo git-merge foo\n> > git-pull git-pull --merge\n> > git-merge git-merge-driver\n> > \n> > in other words pull does the download and doesn't automatically\n> > start a merge unless --merge was also given and git-merge is a\n> > cleaner wrapper around the Grand Unified Merge Driver that makes\n> > it easier to start a merge.\n> \n> I must say that I second this. Although I'm rather familiar with GIT I \n> still feel unconfortable with the current naming and behavior.\n\nOriginally, I wanted to shut up about this issue. But since there are two \nvoices against the current naming, I want to speak for it.\n\nWhen I was introduced to CVS, _I_ found the _CVS_ names misleading. I \nthought that cvs update would throw away my changes.\n\nSo let's face it, a single name cannot possibly convey the meaning to that \nmany people, and therefore, it is _necessary_ to have a nice short \nintroduction, after which users actually know that git-pull is a fetch + \nmerge. Once you know it, what can possibly go wrong? ;-)\n\nCiao,\nDscho\n"},{"id":"27381","messageId":"eeuhe8$i66$1@sea.gmane.org","threadId":"5639","inReplyTo":"Pine.LNX.4.64.0609211259340.2627@xanadu.home","subject":"Re: Git user survey and `git pull`","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-21T17:17:05Z","receivedAt":"2006-09-21T17:17:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> On Thu, 21 Sep 2006, Shawn Pearce wrote:\n> \n>> I think its probably too late to change the UI[*1*] but I think\n>> it is definately an issue for folks learning Git. Calling push\n>> push, fetch fetch and fetch+merge pull is probably a design flaw.\n>> IMHO it probably should have been something like:\n>> \n>> Current Shoulda Been\n>> --------------- ----------------\n>> git-push git-push\n>> git-fetch git-pull\n>> git-pull . foo git-merge foo\n>> git-pull git-pull --merge\n>> git-merge git-merge-driver\n>> \n>> in other words pull does the download and doesn't automatically\n>> start a merge unless --merge was also given and git-merge is a\n>> cleaner wrapper around the Grand Unified Merge Driver that makes\n>> it easier to start a merge.\n> \n> I must say that I second this. Although I'm rather familiar with GIT I \n> still feel unconfortable with the current naming and behavior.\n\nUsing git-pull . for _merge_, and git-merge being mid-level\ncommand (one of the arguments is , instead of having git-commit like\nways to provide/amend commit message) is somewhat confusing.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27382","messageId":"Pine.LNX.4.64.0609211027440.4388@g5.osdl.org","threadId":"5639","inReplyTo":"20060921164048.GY8259@pasky.or.cz","subject":"Re: Git user survey and `git pull`","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-21T17:38:04Z","receivedAt":"2006-09-21T17:38:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 21 Sep 2006, Petr Baudis wrote:\n> \n> This is artifact of the BitKeeper terminology. This is the meaning in\n> most other VCSes but in BitKeeper, pull meant \"get changes and merge\n> them\", not just \"get changes\". So the BitKeeper legacy lives on. :-)\n\nIndeed. \"pull/push\" are the operations bk has. \n\nBK doesn't have branches, and cannot do a \"fetch\", so there's no confusion \nin BK - the pulls and the pushes are not mirror-images, but since there \nare no other operations you'd normally use, you can pretty much ignore it.\n\n(That's not entirely true. In BK, you can do \"bk receive\" and \"bk resolve\" \nto \"fetch\" and \"merge\" another branch, but quite frankly, I personally \nfound them so confusing that I never used them at all).\n\nI agree that the clarifications from Shawn are probably improvements, but \nI'd actually like to solve the problem a bit differently. Namely, I was \nhoping that the per-branch configuration would solve the confusion.\n\nRight now, a plain \"git pull\" means \"fetch all branches and merge the \nfirst one\", and the thing is, that's generally the right thing _only_ if \nyou pull into \"master\".\n\nIt's usually exactly the _wrong_ thing to do for any other branch. In \nparticular, if you work with a project that has lots of branches, and \nyou're working in another branch (that is directly tracking a remote, for \nexample), doing a \"git pull\" definitely should _not_ merge the first head. \nIt should fetch everything, and possibly merge the _matching_ head.\n\nWhich it doesn't do right now.\n\nSo I think the problem with \"git pull\" is not that it's a \"fetch and \nmerge\", it's that it merges the wrong head. It always merges the first \nremote one (aka the remote \"HEAD\"), regardless of which head we happen to \nbe at right now.\n\nSo I was kind of hoping that the per-branch configuration stuff (that \npetered out after the .git/config file format was worked out) would solve \nthe problem.\n\nThat said, maybe Shawn's suggestion is better. And maybe the fact that \nwe'd change the semantics mid-stream would make things even WORSE. I \ndunno.\n\n\t\tLinus\n"},{"id":"27385","messageId":"Pine.LNX.4.64.0609211357450.2627@xanadu.home","threadId":"5639","inReplyTo":"Pine.LNX.4.64.0609211027440.4388@g5.osdl.org","subject":"Re: Git user survey and `git pull`","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-09-21T18:05:11Z","receivedAt":"2006-09-21T18:05:11Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 21 Sep 2006, Linus Torvalds wrote:\n\n> Right now, a plain \"git pull\" means \"fetch all branches and merge the \n> first one\", and the thing is, that's generally the right thing _only_ if \n> you pull into \"master\".\n> \n> It's usually exactly the _wrong_ thing to do for any other branch. In \n> particular, if you work with a project that has lots of branches, and \n> you're working in another branch (that is directly tracking a remote, for \n> example), doing a \"git pull\" definitely should _not_ merge the first head. \n> It should fetch everything, and possibly merge the _matching_ head.\n> \n> Which it doesn't do right now.\n\nI think you're summarizing my grip about git pull quite well. This is \nreally counter-intuitive and I've been bitten by that behavior on many \noccasions.\n\n\nNicolas\n"},{"id":"27405","messageId":"7vu0305wh8.fsf@assigned-by-dhcp.cox.net","threadId":"5639","inReplyTo":"Pine.LNX.4.64.0609211027440.4388@g5.osdl.org","subject":"Re: Git user survey and `git pull`","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-22T04:57:55Z","receivedAt":"2006-09-22T04:57:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I agree that the clarifications from Shawn are probably improvements, but \n> I'd actually like to solve the problem a bit differently. Namely, I was \n> hoping that the per-branch configuration would solve the confusion.\n>\n> Right now, a plain \"git pull\" means \"fetch all branches and merge the \n> first one\", and the thing is, that's generally the right thing _only_ if \n> you pull into \"master\".\n>\n> It's usually exactly the _wrong_ thing to do for any other branch. In \n> particular, if you work with a project that has lots of branches, and \n> you're working in another branch (that is directly tracking a remote, for \n> example), doing a \"git pull\" definitely should _not_ merge the first head. \n> It should fetch everything, and possibly merge the _matching_ head.\n>\n> Which it doesn't do right now.\n\nI am actually in favor of adding config mechanism that lets you\nsay things like:\n\n When on branch 'foo':\n\n - pull without any argument shall use .git/remotes/$that,\n instead of the usual .git/remotes/origin;\n\n - pull without pathspec arguments shall use the named\n .git/remotes/ file to learn from which URL to fetch from,\n which remote branches to fetch and which local branches to\n store them, but merge $this_and_that remote heads regardless\n of what .git/remotes/ file says;\n\n - you shall not use \"reset\" other than resetting to the HEAD;\n\n - you shall not use \"rebase\";\n\n - you shall not merge from $this_and_that branches;\n\n - your commit identity shall be $whoami, not the usual\n core.user;\n\nI am not motivated enough to do that myself, though.\n"},{"id":"27409","messageId":"8aa486160609220334w39a7d455s66f815f00ef6b6f6@mail.gmail.com","threadId":"5639","inReplyTo":"7vu0305wh8.fsf@assigned-by-dhcp.cox.net","subject":"Re: Git user survey and `git pull`","fromName":"Santi","fromEmail":"sbejar@gmail.com","sentAt":"2006-09-22T10:34:43Z","receivedAt":"2006-09-22T10:34:43Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"2006/9/22, Junio C Hamano :\n> I am actually in favor of adding config mechanism that lets you\n> say things like:\n>\n> When on branch 'foo':\n>\n> - pull without any argument shall use .git/remotes/$that,\n> instead of the usual .git/remotes/origin;\n>\n> - pull without pathspec arguments shall use the named\n> .git/remotes/ file to learn from which URL to fetch from,\n> which remote branches to fetch and which local branches to\n> store them, but merge $this_and_that remote heads regardless\n> of what .git/remotes/ file says;\n>\n\nSomething like\nhttp://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2\n?\n\n Santi\n"},{"id":"27417","messageId":"7v4puz4t3z.fsf@assigned-by-dhcp.cox.net","threadId":"5639","inReplyTo":"8aa486160609220334w39a7d455s66f815f00ef6b6f6@mail.gmail.com","subject":"Re: Git user survey and `git pull`","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-22T19:08:16Z","receivedAt":"2006-09-22T19:08:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Santi writes:\n\n> Something like\n> http://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2\n> ?\n\nI do not have access to marc at the moment but I have saved a\npatch from you back from July in one of my freezer mbox. IIRC\nyour message was not for inclusion but more as a firestarter for\ndiscussions, and the discussion never came to conclusion with \nappliable set of patches.\n"},{"id":"27448","messageId":"ef1j6j$8sn$1@sea.gmane.org","threadId":"5639","inReplyTo":"20060921162401.GD3934@spearce.org","subject":"Re: Git user survey and `git pull`","fromName":"Matthias Urlichs","fromEmail":"matthias@urlichs.de","sentAt":"2006-09-22T21:05:23Z","receivedAt":"2006-09-22T21:05:23Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"For what it's worth, I'm in favor of renaming the things.\n\nIMHO, we do not need that kind of baggage. Sure, you explain it once and\npeople hopefully remember -- except that they don't, not always anyway,\nand novice users can't be expected to be notice, let alone repair, that\nkind of damage.\n\n*I* make that stupid pull/fetch/merge mistake sometimes, \nand I'm not exactly new to git...\n\n\nOn Thu, 21 Sep 2006 12:24:01 -0400, Shawn Pearce wrote:\n\n> Current Shoulda Been\n> --------------- ----------------\n> git-push git-push\n> git-fetch git-pull\n> git-pull . foo git-merge foo\n> git-pull git-pull --merge\n> git-merge git-merge-driver\n> \nThe new programs can (for the most part) recognize when they're called with\n\"old\" semantics, and spit out a warning.\n\n-- \nMatthias Urlichs\n"},{"id":"27428","messageId":"8aa486160609221624h41685024k29b63baa0a0bcf99@mail.gmail.com","threadId":"5639","inReplyTo":"7v4puz4t3z.fsf@assigned-by-dhcp.cox.net","subject":"Re: Git user survey and `git pull`","fromName":"Santi","fromEmail":"sbejar@gmail.com","sentAt":"2006-09-22T23:24:20Z","receivedAt":"2006-09-22T23:24:20Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"2006/9/22, Junio C Hamano :\n> Santi writes:\n>\n> > Something like\n> > http://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2\n> > ?\n>\n> I do not have access to marc at the moment but I have saved a\n> patch from you back from July in one of my freezer mbox. IIRC\n> your message was not for inclusion but more as a firestarter for\n> discussions, and the discussion never came to conclusion with\n> appliable set of patches.\n>\n\nYes, it was. But I think now will be different :)\n\nIn a moment I'll send two little patches for your two first points\n(pull w/o arg + pull with just the remote).\n\nSanti\n"},{"id":"27455","messageId":"ef2snp$bcp$1@sea.gmane.org","threadId":"5639","inReplyTo":"20060921162401.GD3934@spearce.org","subject":"Re: Git user survey and `git pull`","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-23T08:54:22Z","receivedAt":"2006-09-23T08:54:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn Pearce wrote:\n\n>   git-pull           git-pull --merge\n\nAnd we can even have \"git-pull --merge=\"\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27466","messageId":"200609231251.23214.alan@chandlerfamily.org.uk","threadId":"5639","inReplyTo":"ef1j6j$8sn$1@sea.gmane.org","subject":"Re: Git user survey and `git pull`","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-09-23T11:51:23Z","receivedAt":"2006-09-23T11:51:23Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 22 September 2006 22:05, Matthias Urlichs wrote:\n> For what it's worth, I'm in favor of renaming the things.\n\nMe too. I am continually coming back to things after a couple of months and \nhaving to relearn everything from scratch. I never over the hump of even \nbecoming an intermediate user of anything.\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"27475","messageId":"Pine.LNX.4.63.0609231608070.25853@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5639","inReplyTo":"ef1j6j$8sn$1@sea.gmane.org","subject":"Re: Git user survey and `git pull`","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-23T14:12:00Z","receivedAt":"2006-09-23T14:12:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 22 Sep 2006, Matthias Urlichs wrote:\n\n> For what it's worth, I'm in favor of renaming the things.\n> \n> On Thu, 21 Sep 2006 12:24:01 -0400, Shawn Pearce wrote:\n> \n> > Current Shoulda Been\n> > --------------- ----------------\n> > git-push git-push\n> > git-fetch git-pull\n> > git-pull . foo git-merge foo\n> > git-pull git-pull --merge\n> > git-merge git-merge-driver\n> > \n> The new programs can (for the most part) recognize when they're called with\n> \"old\" semantics, and spit out a warning.\n\nNow, that only introduces more confusion!\n\nIf there is another tool rename, better choose names which are virgins. \nBesides, I am still not convinced that the rename is necessary. Granted, \nsome new users might get confused with the current naming, but what about \nthose who are not? They would be confused by the new naming.\n\nAnd if you want unambiguous names, and even succeed in choosing sensible \nones, you can make them hardwired aliases, and old habits don't have to \ndie.\n\nCiao,\nDscho\n"}]}