{"thread":{"id":"21298","subject":"[RFC] pull/fetch rename","startedAt":"2009-10-20T17:47:45Z","lastAt":"2009-10-24T06:30:16Z","messageCount":32,"participants":["Thomas Rast","Wesley J. Landaker","Nanako Shiraishi","Junio C Hamano","Daniel Barkalow","Björn Steinbrink","Mike Hommey","Jeff King","Clemens Buchacher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125500","messageId":"200910201947.50423.trast@student.ethz.ch","threadId":"21298","inReplyTo":null,"subject":"[RFC] pull/fetch rename","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-20T17:47:45Z","receivedAt":"2009-10-20T17:47:45Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hi all,\n\nWhile everyone is busy in two other UI threads, I figured I might as\nwell toss up another (probably) controversial topic.\n\nEspecially on IRC, we see many people who are some combination of\nmisunderstanding, misusing or overusing git-pull. I figure this is\nthe result of several factors, notably\n\na) pull/push are not symmetric,\n\nb) guides/tutorials recommend pull for situations where they\n shouldn't,\n\nc) people blindly fire commands at git.\n\nWhile the latter two are probably hopeless, I find (a) rather\nannoying. It breaks everyone's intuition of git-pull when they first\nsee it. (I know that BK has a pull that also merges, but I gather\nfrom the manual [never used it] that you cannot do the equivalent of\ngit-fetch in BK.)\n\nAs you probably guessed by now, here is an idea for a very aggressive\ntransition plan to address (a) in four phases:\n\n1. git-fetch gets options --merge/-m and --rebase that make it behave\n like (current) git-pull, but requiring explicit arguments.\n git-pull gets a new option --merge (-m) that only enforces presence\n of arguments.\n\n2. git-pull refuses to do any work unless given either --merge or\n --rebase. Deprecation warnings for this start at the same time as\n (1.).\n\n3. git-pull becomes a synonym for git-fetch.\n\n4. git-fetch gives deprecation warnings that point the user to\n git-pull instead.\n\n(1.) is probably harmless and could be put into any particular\nrelease. (2.) obviously breaks everyone's favourite script and needs\nto fall on a major release. (3.) should be delayed significantly from\n(2.) to allow time to expose such breakage, and similarly (4.) should\nbe delayed after (3.) (or just ignored, but in any case git-pull would\nbecome the preferred spelling).\n\nAs you probably noticed, while 'git pull $remote $ref' only needs to\nbe changed to 'git pull --merge $remote $ref', this leaves a gap at\nthe current functionality of 'git pull' without arguments. Björn laid\nout a nice suggestion for a git-update in\n\n http://article.gmane.org/gmane.comp.version-control.git/130679\n\nbriefly summarised as: git-update would cover what 'git pull' (without\narguments) does right now. However, it could also be restricted to\nfast-forward updates by default (with per-branch configurability as\nwith current git-pull).\n\nComments? Flames? Improvements?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"125514","messageId":"200910201359.30880.wjl@icecavern.net","threadId":"21298","inReplyTo":"200910201947.50423.trast@student.ethz.ch","subject":"Re: [RFC] pull/fetch rename","fromName":"Wesley J. Landaker","fromEmail":"wjl@icecavern.net","sentAt":"2009-10-20T19:59:30Z","receivedAt":"2009-10-20T19:59:30Z","isPatch":false,"sender":{"key":"wjl@icecavern.net","avatar":"https://avatars.githubusercontent.com/u/67229?v=4"},"body":"On Tuesday 20 October 2009 11:47:45 Thomas Rast wrote:\n> Especially on IRC, we see many people who are some combination of\n> misunderstanding, misusing or overusing git-pull. I figure this is\n> the result of several factors, notably\n> \n> a) pull/push are not symmetric,\n> \n> b) guides/tutorials recommend pull for situations where they\n> shouldn't,\n> \n> c) people blindly fire commands at git.\n\nThis may be minor, but also:\n\nd) in mercurial, pull/push are symmetric, but fetch means pull+merge\n\n> As you probably guessed by now, here is an idea for a very aggressive\n> transition plan to address (a) in four phases:\n\nI would love to see this change, not because I get confused about pull/fetch \n(it honestly only took a few days to get used to), but because having \npush/pull be symmetric just is so much more conceptually pure / easier \nexplain to co-workers / separation between orthogonal operations / \nsatisfying to my inner perfectionist / etc.\n \n> 1. git-fetch gets options --merge/-m and --rebase that make it behave\n> like (current) git-pull, but requiring explicit arguments.\n> git-pull gets a new option --merge (-m) that only enforces presence\n> of arguments.\n> \n> 2. git-pull refuses to do any work unless given either --merge or\n> --rebase. Deprecation warnings for this start at the same time as\n> (1.).\n>\n> 3. git-pull becomes a synonym for git-fetch.\n> \n> 4. git-fetch gives deprecation warnings that point the user to\n> git-pull instead.\n\nHmmm, maybe this would be better for easier transition; replace 2-4 above \nwith:\n\n2. git-pull learns --merge and gets a configuration option that allows \nturning auto-merging off (e.g. pull.merge = merge/yes (default), rebase, or \nno). This doesn't change any behavior by default, but allows individual \nusers to essentially make pull == fetch, and is forward compatible with \nchanges up to #4.\n\n3. git-pull gives a deprecation warning if the configuration option is not \nset, but otherwise defaults to merge. To get rid of the warning, you can set \nit explicitly (one way or another).\n\n4. The configuration option default changes to \"no\", and a helpful message \nis printed telling you that you can set the configuration option to merge to \nget the old behavior.\n\n5. Drop deprecation messages. At this point, git fetch and git pull are \nidentical, except git fetch never merges, regardless of the pull \nconfiguration setting.\n\nThis has a few nice properties:\n\n * There is lots and lots of warning; this transition could happen slowly.\n\n * Early on, it will be possible to make git pull have symmetric behavior \nby default, which is the desired endgame.\n\n * In the end, people who want \"git pull\" to always keep it's current \nbehavior can do so by setting the proper configuration variable.\n\n * git fetch doesn't need to be deprecated (but could be).\n"},{"id":"125534","messageId":"20091021064243.6117@nanako3.lavabit.com","threadId":"21298","inReplyTo":"200910201947.50423.trast@student.ethz.ch","subject":"Re: [RFC] pull/fetch rename","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-10-20T21:42:43Z","receivedAt":"2009-10-20T21:42:43Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Thomas Rast \n\n> Especially on IRC, we see many people who are some combination of\n> misunderstanding, misusing or overusing git-pull. I figure this is\n> the result of several factors, notably\n>\n> a) pull/push are not symmetric,\n>\n> b) guides/tutorials recommend pull for situations where they\n> shouldn't,\n>\n> c) people blindly fire commands at git.\n>\n> While the latter two are probably hopeless, I find (a) rather\n> annoying. It breaks everyone's intuition of git-pull when they first\n> see it. (I know that BK has a pull that also merges, but I gather\n> from the manual [never used it] that you cannot do the equivalent of\n> git-fetch in BK.)\n>\n> As you probably guessed by now, here is an idea for a very aggressive\n> transition plan to address (a) in four phases:\n>\n> 1. git-fetch gets options --merge/-m and --rebase that make it behave\n> like (current) git-pull, but requiring explicit arguments.\n> git-pull gets a new option --merge (-m) that only enforces presence\n> of arguments.\n>\n> 2. git-pull refuses to do any work unless given either --merge or\n> --rebase. Deprecation warnings for this start at the same time as\n> (1.).\n>\n> 3. git-pull becomes a synonym for git-fetch.\n>\n> 4. git-fetch gives deprecation warnings that point the user to\n> git-pull instead.\n>\n> (1.) is probably harmless and could be put into any particular\n> release. (2.) obviously breaks everyone's favourite script and needs\n> to fall on a major release. (3.) should be delayed significantly from\n> (2.) to allow time to expose such breakage, and similarly (4.) should\n> be delayed after (3.) (or just ignored, but in any case git-pull would\n> become the preferred spelling).\n\nSorry, but I don't understand what's the improvement in the end \nresult.\n\nI started reading your problem description and I thought you are \nfixing your item 'a) pull/push are not symmetric' by deprecating \npull, to advertize fetch/push. Then asymmetry of push/pull stops \nbeing an issue.\n\nBut it seems that eventually you will keep git-push and git-pull \n(because git-fetch gets deprecated); you have push/pull that are \nnot symmetric.\n\nWhat's the point of this change then?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"125535","messageId":"7vpr8hlow9.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"200910201359.30880.wjl@icecavern.net","subject":"Re: [RFC] pull/fetch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-20T21:46:30Z","receivedAt":"2009-10-20T21:46:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Wesley J. Landaker\" writes:\n\n> On Tuesday 20 October 2009 11:47:45 Thomas Rast wrote:\n>> Especially on IRC, we see many people who are some combination of\n>> misunderstanding, misusing or overusing git-pull. I figure this is\n>> the result of several factors, notably\n>> \n>> a) pull/push are not symmetric,\n>> \n>> b) guides/tutorials recommend pull for situations where they\n>> shouldn't,\n>> \n>> c) people blindly fire commands at git.\n>\n> This may be minor, but also:\n>\n> d) in mercurial, pull/push are symmetric, but fetch means pull+merge\n>\n>> As you probably guessed by now, here is an idea for a very aggressive\n>> transition plan to address (a) in four phases:\n>\n> I would love to see this change, not because I get confused about pull/fetch \n> (it honestly only took a few days to get used to), but because having \n> push/pull be symmetric just is so much more conceptually pure / easier \n> explain to co-workers / separation between orthogonal operations / \n> satisfying to my inner perfectionist / etc.\n\nIs making \"pull\" a symmetric opposite of \"push\" the ultimate goal?\n\nOr is making (or rather \"keeping\") \"pull\" useful more important?\n\nIt is not even an attitude that values philosophy over utility.\n\nFundamentally, pull and push cannot be symmetric because nobody is sitting\nin front of the repository you are pushing into (that is what a \"push\" is;\nyou push from outside the repository---otherwise you would be \"pull\"ing\nfrom inside it in the other direction), but you know you are sitting in\nthe repository, ready to resolve potential conflicts, when you say \"pull\".\n\nYour elaborate scheme to make \"pull\" into \"fetch\" and to force everybody\nto set a configuration variable to make it \"pull\" again sounds like a\nmindless mental masturbation to me. People who leave \"pull.merge = no\"\nwill always have to say \"pull --merge\" or \"pull --rebase\", so you cannot\neven argue you are not forcing but giving them a choice.\n\nAnd you are doing this for what gain? The only thing I can think of is\n\"People who deliberately set 'pull.merge = yes' can no longer blame us for\npull not being the opposite of push.\" I do not consider it as a gain.\n\nI do not buy \"People who set 'pull.merge = yes' now understand why pull\ntouches their work tree, because they did it themselves\" either. People\nblindly copy other people's configuration from random web pages without\nunderstanding. Besides, the next thing they will ask is \"Why is there\npull.merge but no push.merge? Wasn't push an opposite of pull?\" and you\nare back to square one.\n\nI would be much more sympathetic if the suggested approach were to make\n\"push\" more symmetric to \"pull\", or at least attempt to allow it to be, by\ngiving it an option to update the associated work tree when it can [*1*].\n\nBut I do not know what to say when people say \"push cannot update the work\ntree, so let's make pull not to update the work tree by default---it will\nmake it much less useful so we will fix that regression with yet another\nconfiguration option\". It's not even funny.\n\n\n[Footnote]\n\n*1* Obviously you cannot do this most of the time _if_ the work tree has\nan interactive user sitting in front of it, but in a repository that never\nallows a non-ff push, with a work tree that is never updated except by\nsuch a push, can reasonably be maintained to give an illusion of push\nbeing an opposite of pull by fast forwarding the work tree when the push\nupdates HEAD.\n"},{"id":"125543","messageId":"200910210041.12738.trast@student.ethz.ch","threadId":"21298","inReplyTo":"20091021064243.6117@nanako3.lavabit.com","subject":"Re: [RFC] pull/fetch rename","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-20T22:41:11Z","receivedAt":"2009-10-20T22:41:11Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Nanako Shiraishi wrote:\n> Quoting Thomas Rast \n> > 1. git-fetch gets options --merge/-m and --rebase that make it behave\n> > like (current) git-pull, but requiring explicit arguments.\n> > git-pull gets a new option --merge (-m) that only enforces presence\n> > of arguments.\n> >\n> > 2. git-pull refuses to do any work unless given either --merge or\n> > --rebase. Deprecation warnings for this start at the same time as\n> > (1.).\n> >\n> > 3. git-pull becomes a synonym for git-fetch.\n> >\n> > 4. git-fetch gives deprecation warnings that point the user to\n> > git-pull instead.\n> \n> Sorry, but I don't understand what's the improvement in the end \n> result.\n> \n> I started reading your problem description and I thought you are \n> fixing your item 'a) pull/push are not symmetric' by deprecating \n> pull, to advertize fetch/push. Then asymmetry of push/pull stops \n> being an issue.\n> \n> But it seems that eventually you will keep git-push and git-pull \n> (because git-fetch gets deprecated); you have push/pull that are \n> not symmetric.\n\nBy the time I get to that step, new-pull is current-fetch. So by that\ntime, push/pull *are* supposedly symmetric.\n\n(Only deprecating pull never occurred to me, but then I really think\nthe strong association between them makes it worth keeping pull as the\nopposite of push.)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"125545","messageId":"200910210053.29794.trast@student.ethz.ch","threadId":"21298","inReplyTo":"7vpr8hlow9.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-20T22:53:28Z","receivedAt":"2009-10-20T22:53:28Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> \"Wesley J. Landaker\" writes:\n> > d) in mercurial, pull/push are symmetric, but fetch means pull+merge\n\nUgh. I can see how they arrived at hg-pull == git-fetch, but why on\nearth was the logical next step hg-fetch == git-pull?!\n\n\n\n> > I would love to see this change, not because I get confused about pull/fetch \n> > (it honestly only took a few days to get used to), but because having \n> > push/pull be symmetric just is so much more conceptually pure / easier \n> > explain to co-workers / separation between orthogonal operations / \n> > satisfying to my inner perfectionist / etc.\n> \n> Is making \"pull\" a symmetric opposite of \"push\" the ultimate goal?\n> \n> Or is making (or rather \"keeping\") \"pull\" useful more important?\n> \n> It is not even an attitude that values philosophy over utility.\n> \n> Fundamentally, pull and push cannot be symmetric because nobody is sitting\n> in front of the repository you are pushing into (that is what a \"push\" is;\n> you push from outside the repository---otherwise you would be \"pull\"ing\n> from inside it in the other direction), but you know you are sitting in\n> the repository, ready to resolve potential conflicts, when you say \"pull\".\n\nWell, I'd rather not argue the little semantic details, but I think\nwith the changes to disallow pushing into HEAD, push and fetch are as\nsymmetric as it gets. Both are exactly and only about transmitting\nrefs with their associated commits to the other side. Which one you\npick only depends on which side you sit on.\n\nOTOH pull is about merging. And we can repeat the \"pull = fetch +\nmerge\" mantra to ourselves all we like, having pull as \"the opposite\nof push\" is conceptually much easier to understand and thus far easier\nto explain to new users.\n\n> And you are doing this for what gain? The only thing I can think of is\n> \"People who deliberately set 'pull.merge = yes' can no longer blame us for\n> pull not being the opposite of push.\" I do not consider it as a gain.\n> \n> I do not buy \"People who set 'pull.merge = yes' now understand why pull\n> touches their work tree, because they did it themselves\" either.\n[...]\n> But I do not know what to say when people say \"push cannot update the work\n> tree, so let's make pull not to update the work tree by default---it will\n> make it much less useful so we will fix that regression with yet another\n> configuration option\".\n\nThere would not be a configuration option.\n\nReally, the whole goal would be to make pull the opposite of push. No\nexceptions, and most certainly no little loopholes to escape into the\nmerging behaviour by default. The current 'git pull' behaviour would\neither be obtained through a new command, or through an explicit\nswitch.\n\n> I would be much more sympathetic if the suggested approach were to make\n> \"push\" more symmetric to \"pull\", or at least attempt to allow it to be, by\n> giving it an option to update the associated work tree when it can [*1*].\n[...]\n> *1* Obviously you cannot do this most of the time _if_ the work tree has\n> an interactive user sitting in front of it, but in a repository that never\n> allows a non-ff push, with a work tree that is never updated except by\n> such a push, can reasonably be maintained to give an illusion of push\n> being an opposite of pull by fast forwarding the work tree when the push\n> updates HEAD.\n\nWell, that reminds me of\n\n http://thread.gmane.org/gmane.comp.version-control.git/110251\n\nbut was not really what I was aiming at.\n\n> It's not even funny.\n\nIt was an RFC, not a joke ;-)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"125548","messageId":"7v7huplkyj.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"200910210053.29794.trast@student.ethz.ch","subject":"Re: [RFC] pull/fetch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-20T23:11:32Z","receivedAt":"2009-10-20T23:11:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Junio C Hamano wrote:\n>> \"Wesley J. Landaker\" writes:\n> ...\n> There would not be a configuration option.\n> ...\n>> It's not even funny.\n\nRe-read what you were responding to and notice that I was commenting on\nWesley's proposal that _is_ about a configuration variable.\n"},{"id":"125549","messageId":"7v3a5dlkqy.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"200910210053.29794.trast@student.ethz.ch","subject":"Re: [RFC] pull/fetch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-20T23:16:05Z","receivedAt":"2009-10-20T23:16:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Well, that reminds me of\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/110251\n>\n> but was not really what I was aiming at.\n\nActually, if that patch weren't marked as [DRY HUMOR PATCH], and if it did\nnot have the detachInstead option, I would have at least queued it to\n'pu', if not 'next'.\n"},{"id":"125552","messageId":"alpine.LNX.2.00.0910201912390.14365@iabervon.org","threadId":"21298","inReplyTo":"200910201947.50423.trast@student.ethz.ch","subject":"Re: [RFC] pull/fetch rename","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-20T23:56:01Z","receivedAt":"2009-10-20T23:56:01Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Oct 2009, Thomas Rast wrote:\n\n> Hi all,\n> \n> While everyone is busy in two other UI threads, I figured I might as\n> well toss up another (probably) controversial topic.\n> \n> Especially on IRC, we see many people who are some combination of\n> misunderstanding, misusing or overusing git-pull. I figure this is\n> the result of several factors, notably\n> \n> a) pull/push are not symmetric,\n\nIn a certain sense they are; they both update the branches local to one \nrepository with the data from the other repository. In this sense, fetch \nis the oddity in that it doesn't update any repository's own branches, but \njust the local information about other repositories' branches.\n\nIn another sense, push is unlike anything else in that it updates \nsomething that's remote; in a third sense, pull is unique in that it can \ngenerate a merge.\n\nI suspect that what we've called \"fetch\" isn't what the people want when \nthey type \"pull\", either. And I suspect that the fundamental issue is that \nthe operation people are looking for is not the operation that they would \ndo best to use, regardless of naming. I think users are looking for \nsomething that corresponds to \"svn up\", and they find \"git pull\"; this \nisn't going to make them happy git users, but finding \"git fetch\" instead \nis going to make them even more confused.\n\nBut I don't really know; are there IRC logs you can quote or reference \nwith people making the mistake you're trying to help them avoid?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"125559","messageId":"200910202001.44079.wjl@icecavern.net","threadId":"21298","inReplyTo":"7v7huplkyj.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Wesley J. Landaker","fromEmail":"wjl@icecavern.net","sentAt":"2009-10-21T02:01:43Z","receivedAt":"2009-10-21T02:01:43Z","isPatch":false,"sender":{"key":"wjl@icecavern.net","avatar":"https://avatars.githubusercontent.com/u/67229?v=4"},"body":"On Tuesday 20 October 2009 17:11:32 Junio C Hamano wrote:\n> Thomas Rast writes:\n> > Junio C Hamano wrote:\n> >> \"Wesley J. Landaker\" writes:\n> >\n> > ...\n> > There would not be a configuration option.\n> > ...\n> >\n> >> It's not even funny.\n> \n> Re-read what you were responding to and notice that I was commenting on\n> Wesley's proposal that _is_ about a configuration variable.\n\nYes, I brought up the configuration variable, not Thomas. \n\nMy main goal was to try to suggest a transition plan that would be less \npainful, but maybe it was actually worse. After reading Junio's response I \nthink I agree that going down that path might be the worst of both worlds, \nbut the basic model I was proposing (even if it's a bad idea in this case) \nwas largely basing on (my perceived impression of) how the recent changes to \npush behavior were staged (i.e. with deprecation, new configuration \nvariables, etc).\n\nI still think that, long term, making push and pull symmetric, EITHER by 1) \nmaking push also update the working tree (in some sane way that I don't have \na proposal for) or 2) making pull be just about transfering objects, not \nalso merging (in some reasonable way that doesn't break useability, like \nalso adding \"git update\" or something at the same time) would be an overall \nbenefit.\n"},{"id":"125560","messageId":"20091021030608.GA18997@atjola.homenet","threadId":"21298","inReplyTo":"alpine.LNX.2.00.0910201912390.14365@iabervon.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-10-21T03:06:08Z","receivedAt":"2009-10-21T03:06:08Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.10.20 19:56:01 -0400, Daniel Barkalow wrote:\n> But I don't really know; are there IRC logs you can quote or reference \n> with people making the mistake you're trying to help them avoid?\n\n\"git pull\" is kind of a jack of all trades WRT user errors, so I'll just\npick up examples of all kinds, this might get long...\n\n[If you read this and find out that you're quoted/referenced here: I\ndon't mean to blame or embarrass you, or to point out that you're stupid\nor whatever. Quite contrary, I just want to show how git's pull UI _might_\nbe responsible for your mistakes. The comments I made are purely my,\npossibly biased, reaction to what happened.]\n\nThat said, here we go:\n\n1) Unexpected fast-forward even with --no-ff\n\n\"git pull --no-ff abc:abc\" with \"abc\" being checked out.\n\nAs pull explicitly allows fetches into the checked out branch head, this\nfirst fast-forwards abc, and updates the working tree/index. And then\nthe --no-ff merge is a no-op.\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l2080\n(Should be a catchable special case, and the special --update-head-ok\nhandling of \"git pull\" is from times where git didn't have remote\ntracking branches. I'd argue that that support should be dropped or at\nleast disabled when you're using the modern setup, might be kept for\noldtimers still using .git/remotes/*. Dunno...)\n\n\n2) \"git pull\" taken as \"reset --hard\"\ngit checkout -b foo; git pull origin bar\n\nThe user actually just wanted to look at things and thus was ok with:\ngit fetch origin; git checkout origin/bar\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l1807\n(user seemed to be so inclined to use \"pull\" that he initially didn't\neven realize that he didn't want to merge when I asked whether that's\nwhat he wants)\n\n\n3) User expects \"pull\" to update all branch heads that have a configured\nupstream\n\n08:31 \tdimsuz \thi guys! suppose i'm currently on master. then run git\n\t\tfetch. which delivers updates to master and other\n\t\tbranches. I don't merge anything, but do checkout some\n\t\tbranch (which is not master). Question: will these new\n\t\tupdates get into this branch automatically after i check\n\t\tit out? question2: will branch master contain those\n\t\tupdates when i ckeck it out later?\n08:32 \tCircuitsoft \tdimsuz. After a fetch, no.\n08:33 \tCircuitsoft \tHowever, if you pull, any branches that were set\n\t\t\tup as local tracking branches will get updated.\n08:33 \tCircuitsoft \tOtherwise, only remote tracking branches will be\n\t\t\tupdated.\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969\n(No idea about that one, have seen that once before, but it's definitely\nnot even remotely as common as the others)\n\n\n4) User expects \"pull\" to create branches\n\n07:25 \tfynn \tHey, I just pulled a branch from remote, and I don't see\n\t\tit in \"git branch\"\n07:25 \tdoener \tfynn: if you \"pull\" that means \"fetch this and merge it\n\t\tto what I have checked out\"\n07:25 \tfynn \tdoener: hm, I just did \"git pull\" and it showed the new\n\t\tbranch\n07:26 \tfynn \tbut I don't see it in my branches...\n07:26 \tfynn \tdoener: should I create that branch as a tracking branch\n\t\tfirst?\n07:26 \tdoener \tfynn: you're looking at \"git branch -r\" or \"git branch\n\t\t-a\", right?\n07:26 \tfynn \tdoener: yeah, I'm seeing it in origin/foo, but not\n\t\tlocal.\n07:26 \tdoener \tfynn: the \"git fetch\" should have created a remote\n\t\ttracking branch, as usual, not a local branch head\n\t\t(which would be shown by just \"git branch\")\n07:27 \tfynn \tdoener: OK, what should I do to create it locally then?\n07:28 \tdoener \tfynn: just the usual \"git branch foo origin/foo\", or to\n\t\tcheckout at the same time: \"git checkout -b foo\n\t\torigin/foo\" or \"git checkout -t origin/foo\" (shortcut)\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830\n(Note how my \"fetch this and merge it\" is actually inaccurate for just\n\"git pull\", there is no \"this\" and that case. I took \"pulled a branch\"\nto mean that he did \"git pull \", which wouldn't have\ncreated/update the remote tracking branch [or did patches for that go\nin? I lost track...])\n\n\n4b) User expects pull to create a branch head\n\n09:58 \taraujo \tgit pull origin \n09:58 \taraujo \twill get me the new branch from repo right?\n10:00 \tcharon \taraujo: no, that will fetch *and merge* that branch\n10:00 \taraujo \tcharon, how to just pull?\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l1152\n(Note how he asked \"how to just pull?\", even after being told that pull\nisn't what he wants)\n\n\n5) User possibly expecting \"pull\" to be able to act as \"reset --hard\"\n\n21:01 \taidan \tWhat do I do about this: html/config/core.php: needs\n\t\tupdate\n21:02 \taidan \tgit pull (gives that)\n21:02 \tIlari \taidan: You have uncommitted changes to that file...\n21:15 \taidan \tIlari: how can I just pull master and overwrite any\n\t\tchanges?\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130\n(I'm not sure about that one, \"overwrite any changes\" might mean \"drop\nuncommitted changes and merge\" or \"just get me the remote's state,\ndropping my commits and uncommitted changes\". Most of the time I've seen\nsimilar requests, the user wanted the latter).\n\n\n6) User says \"pull\" but probably means \"fetch\"\n\n14:08 \tAlien_Freak \tonce I have a clone of a repo I know you can do\n\t\t\ta checkout tag but is there anyway to pull just\n\t\t\tthe tag?\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664\n(There was no answer, thus it's hard to tell, but I guess he wanted\nsomething like:\ngit init; git fetch --no-tags url tag ; git checkout \nAt least I'm quite sure he didn't mean \"pull\" as in \"git pull\")\n\n\n7) User expecting \"pull\" to just do fast-forwards (or so)\n\n13:18 \tohadlevy \tI'm getting a merge commit message after each\n\t\t\ttime i do git pull, i didnt have it before,\n\t\t\twhere should I look?\n13:20 \tcharon \tohadlevy: pull merges; you may just have hit lucky so\n\t\tfar, and always had a fast-forward merge\n13:20 \tohadlevy \tcharon: any way I could avoid these commits?\n\t\t\tjust rebasing? its a pure RO repo\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1579\n(Apparently, user was tricked by the fast-forward behaviour he\nexperienced earlier. I don't see any solution to this, except for\ndefaulting to fast-forward-only and requiring a --merge flag (which\nmight imply --no-ff), but I'm likely influenced by the \"git update\"\nstuff here)\n\n\n8) \"reset --hard\" again\n\n20:10 \troger_padactor \ti commited then did a pull how do i get back to\n\t\t\tmy commit. the pull over wrote the files\n20:11 \tmerlin83 \troger_padactor: you can't, pull == fetch + hard\n\t\t\treset to latest commit\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306\n(Someone being told that pull is fetch + reset --hard is actually new to\nme. Only saw that as an expectation previously.)\n\n\n9) More \"git pull A:A\"\n\n19:10 \t_hp_ \tanother question, how do I add the remote branch to\n\t\ttrack so I don't have to constantly do git pull origin\n\t\tmasterA:masterA ?\n19:11 \tIlari \t_hp_: Don't use that src:dest with pull!\n(discussion died)\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-12#l2427\n\n\n10) \"pull\" mistaken for \"cvs update\"\n\n07:25 \tAvrem \thow do I use \"git pull\" to do something like what \"cvs\n\t\tupdate\" does ?\n07:25 \tAvrem \twhich is, replaces files I've deleted\n07:25 \tAvrem \tfrom that from the central repository\n07:30 \tomega \tI'm not sure, but can't you git checkout \n\t\tto get them back?\n\nhttp://colabti.de/irclogger/irclogger_log/git?date=2009-10-11#l545\n(This adds a new twist to the \"scm update\" stuff, although svn/hg don't\nseem to have \"restore individual files\" in their \"update\" command, so\nthis might be cvs-only. But it's so long since I used cvs, I don't even\nknow whether this is correct. But it somehow got me thinking about how\n\"update\" is actually also \"downgrade\" in svn/hg, something git does via\n\"checkout\" [which happens to make more sense to me]. And I think it\nshows how \"git pull\" is taken to mean \"update\", even when ignoring the\nspecial behaviour described here. It's not taken to mean \"merge this\",\nbut just \"update to upstream\").\n\n\nSo that's ten days of #git. I left out a bunch of duplications (most\nwere \"pull == fetch\", \"pull == update\" and \"pull to update\nnon-checked-out branch\").\n\nBjörn\n"},{"id":"125563","messageId":"alpine.LNX.2.00.0910202310070.14365@iabervon.org","threadId":"21298","inReplyTo":"20091021030608.GA18997@atjola.homenet","subject":"Re: [RFC] pull/fetch rename","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-21T04:22:18Z","receivedAt":"2009-10-21T04:22:18Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 21 Oct 2009, Björn Steinbrink wrote:\n\n> On 2009.10.20 19:56:01 -0400, Daniel Barkalow wrote:\n> > But I don't really know; are there IRC logs you can quote or reference \n> > with people making the mistake you're trying to help them avoid?\n> \n> \"git pull\" is kind of a jack of all trades WRT user errors, so I'll just\n> pick up examples of all kinds, this might get long...\n> \n> [If you read this and find out that you're quoted/referenced here: I\n> don't mean to blame or embarrass you, or to point out that you're stupid\n> or whatever. Quite contrary, I just want to show how git's pull UI _might_\n> be responsible for your mistakes. The comments I made are purely my,\n> possibly biased, reaction to what happened.]\n> \n> That said, here we go:\n> \n> 1) Unexpected fast-forward even with --no-ff\n> \n> \"git pull --no-ff abc:abc\" with \"abc\" being checked out.\n> \n> As pull explicitly allows fetches into the checked out branch head, this\n> first fast-forwards abc, and updates the working tree/index. And then\n> the --no-ff merge is a no-op.\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l2080\n> (Should be a catchable special case, and the special --update-head-ok\n> handling of \"git pull\" is from times where git didn't have remote\n> tracking branches. I'd argue that that support should be dropped or at\n> least disabled when you're using the modern setup, might be kept for\n> oldtimers still using .git/remotes/*. Dunno...)\n\nYup, I think it would be good to ditch --update-head-ok and simplify the \ncode; I also think it would be nice to prohibit fetching into refs/heads/* \nentirely, but there might be advanced users who actually want to do that.\n\nIn this case, \"git fetch\" has already done something the user didn't want, \nand the pull-specific portion doesn't actually do anything at all.\n\n> 2) \"git pull\" taken as \"reset --hard\"\n> git checkout -b foo; git pull origin bar\n> \n> The user actually just wanted to look at things and thus was ok with:\n> git fetch origin; git checkout origin/bar\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l1807\n> (user seemed to be so inclined to use \"pull\" that he initially didn't\n> even realize that he didn't want to merge when I asked whether that's\n> what he wants)\n\nI think that's a case where the user has been discouraged from using \ndetached HEAD, and is using \"pull\" instead of \"fetch\" in order to update \nthe junk branch he doesn't actually want. If you don't know you don't need \na local branch, and you branch off of a common ancestor, \"pull\" does \nactually do something you want that \"fetch\" doesn't.\n\n> 3) User expects \"pull\" to update all branch heads that have a configured\n> upstream\n> \n> 08:31 \tdimsuz \thi guys! suppose i'm currently on master. then run git\n> \t\tfetch. which delivers updates to master and other\n> \t\tbranches. I don't merge anything, but do checkout some\n> \t\tbranch (which is not master). Question: will these new\n> \t\tupdates get into this branch automatically after i check\n> \t\tit out? question2: will branch master contain those\n> \t\tupdates when i ckeck it out later?\n> 08:32 \tCircuitsoft \tdimsuz. After a fetch, no.\n> 08:33 \tCircuitsoft \tHowever, if you pull, any branches that were set\n> \t\t\tup as local tracking branches will get updated.\n> 08:33 \tCircuitsoft \tOtherwise, only remote tracking branches will be\n> \t\t\tupdated.\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969\n> (No idea about that one, have seen that once before, but it's definitely\n> not even remotely as common as the others)\n\nI'd guess that's due to having local branches with no local changes, just \nto avoid detached HEAD, and therefore thinking it's normal to have a bunch \nof local branches that could be updated without merges. But I'm on a crazy \n\"everybody really wants detached HEAD and is needlessly scared\" kick, and \nI'm probably reading too much into it.\n\n> 4) User expects \"pull\" to create branches\n> \n> 07:25 \tfynn \tHey, I just pulled a branch from remote, and I don't see\n> \t\tit in \"git branch\"\n> 07:25 \tdoener \tfynn: if you \"pull\" that means \"fetch this and merge it\n> \t\tto what I have checked out\"\n> 07:25 \tfynn \tdoener: hm, I just did \"git pull\" and it showed the new\n> \t\tbranch\n> 07:26 \tfynn \tbut I don't see it in my branches...\n> 07:26 \tfynn \tdoener: should I create that branch as a tracking branch\n> \t\tfirst?\n> 07:26 \tdoener \tfynn: you're looking at \"git branch -r\" or \"git branch\n> \t\t-a\", right?\n> 07:26 \tfynn \tdoener: yeah, I'm seeing it in origin/foo, but not\n> \t\tlocal.\n> 07:26 \tdoener \tfynn: the \"git fetch\" should have created a remote\n> \t\ttracking branch, as usual, not a local branch head\n> \t\t(which would be shown by just \"git branch\")\n> 07:27 \tfynn \tdoener: OK, what should I do to create it locally then?\n> 07:28 \tdoener \tfynn: just the usual \"git branch foo origin/foo\", or to\n> \t\tcheckout at the same time: \"git checkout -b foo\n> \t\torigin/foo\" or \"git checkout -t origin/foo\" (shortcut)\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830\n> (Note how my \"fetch this and merge it\" is actually inaccurate for just\n> \"git pull\", there is no \"this\" and that case. I took \"pulled a branch\"\n> to mean that he did \"git pull \", which wouldn't have\n> created/update the remote tracking branch [or did patches for that go\n> in? I lost track...])\n\nThat sounds like a real converse of \"push\", including creating like-named \nlocal branches. Or, perhaps, this is someone expecting that \"pull\" is like \n\"clone\" in creating an initial local branch with the name and value of a \nspecified remote branch.\n\n> 4b) User expects pull to create a branch head\n> \n> 09:58 \taraujo \tgit pull origin \n> 09:58 \taraujo \twill get me the new branch from repo right?\n> 10:00 \tcharon \taraujo: no, that will fetch *and merge* that branch\n> 10:00 \taraujo \tcharon, how to just pull?\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l1152\n> (Note how he asked \"how to just pull?\", even after being told that pull\n> isn't what he wants)\n\nThat's got to be hg usage. He knows the command isn't \"pull\", but he's \nstuck with the operation it performs being pulling. Or maybe he's thinking \nthat the operation is pulling, and the command needs different arguments \nto not merge.\n\n> 5) User possibly expecting \"pull\" to be able to act as \"reset --hard\"\n> \n> 21:01 \taidan \tWhat do I do about this: html/config/core.php: needs\n> \t\tupdate\n> 21:02 \taidan \tgit pull (gives that)\n> 21:02 \tIlari \taidan: You have uncommitted changes to that file...\n> 21:15 \taidan \tIlari: how can I just pull master and overwrite any\n> \t\tchanges?\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130\n> (I'm not sure about that one, \"overwrite any changes\" might mean \"drop\n> uncommitted changes and merge\" or \"just get me the remote's state,\n> dropping my commits and uncommitted changes\". Most of the time I've seen\n> similar requests, the user wanted the latter).\n\nSo I think that's a desire for \"git checkout .\" first of all (with the \nassumption that the content without modifications has to come from \nsomewhere remote). I don't know what's up with people not wanting to save \ntheir commits, though.\n\n> 6) User says \"pull\" but probably means \"fetch\"\n> \n> 14:08 \tAlien_Freak \tonce I have a clone of a repo I know you can do\n> \t\t\ta checkout tag but is there anyway to pull just\n> \t\t\tthe tag?\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664\n> (There was no answer, thus it's hard to tell, but I guess he wanted\n> something like:\n> git init; git fetch --no-tags url tag ; git checkout \n> At least I'm quite sure he didn't mean \"pull\" as in \"git pull\")\n\nI don't know; you can actually do:\n\n$ git init; git pull --no-tags tag \n\nIt updates the master branch and working directory from (nothing) to the \nfetched tag.\n\n> 7) User expecting \"pull\" to just do fast-forwards (or so)\n> \n> 13:18 \tohadlevy \tI'm getting a merge commit message after each\n> \t\t\ttime i do git pull, i didnt have it before,\n> \t\t\twhere should I look?\n> 13:20 \tcharon \tohadlevy: pull merges; you may just have hit lucky so\n> \t\tfar, and always had a fast-forward merge\n> 13:20 \tohadlevy \tcharon: any way I could avoid these commits?\n> \t\t\tjust rebasing? its a pure RO repo\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1579\n> (Apparently, user was tricked by the fast-forward behaviour he\n> experienced earlier. I don't see any solution to this, except for\n> defaulting to fast-forward-only and requiring a --merge flag (which\n> might imply --no-ff), but I'm likely influenced by the \"git update\"\n> stuff here)\n\nAgain, sounds like the user does want to update local branch state, if \nthere is any. Probably doesn't want a local branch, what with being \nconfused at the possibility of having history that's not from the remote.\n\n> 8) \"reset --hard\" again\n> \n> 20:10 \troger_padactor \ti commited then did a pull how do i get back to\n> \t\t\tmy commit. the pull over wrote the files\n> 20:11 \tmerlin83 \troger_padactor: you can't, pull == fetch + hard\n> \t\t\treset to latest commit\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306\n> (Someone being told that pull is fetch + reset --hard is actually new to\n> me. Only saw that as an expectation previously.)\n\nThat's odd. How could you not notice that it doesn't actually do that, \neven if you try to get it to?\n\n> 9) More \"git pull A:A\"\n> \n> 19:10 \t_hp_ \tanother question, how do I add the remote branch to\n> \t\ttrack so I don't have to constantly do git pull origin\n> \t\tmasterA:masterA ?\n> 19:11 \tIlari \t_hp_: Don't use that src:dest with pull!\n> (discussion died)\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-12#l2427\n\nYup. Oh, and it strikes me that this user must have never made any \ncommits, because that would give an error (not fast forward) on the fetch \npart.\n\n> 10) \"pull\" mistaken for \"cvs update\"\n> \n> 07:25 \tAvrem \thow do I use \"git pull\" to do something like what \"cvs\n> \t\tupdate\" does ?\n> 07:25 \tAvrem \twhich is, replaces files I've deleted\n> 07:25 \tAvrem \tfrom that from the central repository\n> 07:30 \tomega \tI'm not sure, but can't you git checkout \n> \t\tto get them back?\n> \n> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-11#l545\n> (This adds a new twist to the \"scm update\" stuff, although svn/hg don't\n> seem to have \"restore individual files\" in their \"update\" command, so\n> this might be cvs-only. But it's so long since I used cvs, I don't even\n> know whether this is correct. But it somehow got me thinking about how\n> \"update\" is actually also \"downgrade\" in svn/hg, something git does via\n> \"checkout\" [which happens to make more sense to me]. And I think it\n> shows how \"git pull\" is taken to mean \"update\", even when ignoring the\n> special behaviour described here. It's not taken to mean \"merge this\",\n> but just \"update to upstream\").\n\n\"cvs update\" can definitely discard uncommitted changes, according to the \n--help text.\n\nActually, I wonder if the right formula is update = fetch + checkout. \nThere are a lot of people (IMHO) want \"git fetch origin; git checkout \norigin/master\", and I think their first idea is \"git update\", but that \ndoesn't exist, and they find \"pull\" as the closest thing.\n\n> So that's ten days of #git. I left out a bunch of duplications (most\n> were \"pull == fetch\", \"pull == update\" and \"pull to update\n> non-checked-out branch\").\n\nVery interesting. I feel like this is a new thing since I last spent much \ntime on IRC, when it was all people pushing into non-bare repositories. \nThanks for taking the time to collect this.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"125566","messageId":"7vk4ypb71j.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"20091021030608.GA18997@atjola.homenet","subject":"Re: [RFC] pull/fetch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T06:22:16Z","receivedAt":"2009-10-21T06:22:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> So that's ten days of #git. I left out a bunch of duplications (most\n> were \"pull == fetch\", \"pull == update\" and \"pull to update\n> non-checked-out branch\").\n\nInteresting; this shows that people who do not understand what \"pull\" does\nexpect different behaviour from \"pull\", use the word \"pull\" to express\nwhat they want to happen, expect other people interpret the word to mean\nthe way they think it does. At the same time, judging from different\nbehaviour expected by these people, push/pull asymmetry does not seem to\nhave much to do with the confusion. If the verb used by people who know\ngit to call this operation were \"distim\", these people would also say\n\"distim\" and expect different things from it. I would foresee exactly the\nsame problem if the verb were \"update\" for that matter.\n\nIt is just natural, as everybody learns a new language by listening how\nothers talk and by imitating them.\n\nAnother thing I noticed while lurning on the #git channel for the past few\ndays is that too much flexibility actually hurts new people. They do not\nwant flexibility, but want to follow a set recipe. It just overwhelms to\nget too much flexibility upfront without enough guidance.\n\nAnd there are too much historical flexibility that remain merely for\nhistorical reasons. We more or less killed the concept of separate object\nstore and $GIT_DIR (i.e.one objects/ directory shared between more than\none .git/ directories) when we made receive-pack aware of alternate\nrepository information---it used to be that objects/ directory did not\nbelong to a single set of refs/ hierarchy, but now it does and the\nreceiving end of \"git push\" uses that knowledge to tell the sender what\nnot to send in order to minimize the transfer. We will be gradually\nkilling other kinds of historical flexibility that do not buy much in\npractice anymore, and that would reduce the issue of overwhelming\nflexibility.\n\nFor example, I am in favor of deprecating the \"pull $there $src:$dst\"\nnotation. Before we standardized on the separate remote layout, it was\nsometimes handy to be able to use $dst that is a local branch, but these\ndays, especially when repository $there has remote.$there.fetch mapping\nconfigured so that we can compute from $src what remote tracking branch we\nshould store the fetched commit, the flexibility is more confusing than it\nis useful. \"pull $there $src\" (and \"pull $there $src1 $src2\" to build an\noctopus) should stay, but even there, it probably is a good idea for these\nnotations to start updating remote tracking branches for $src ($src1 and\n$src2 in the octopus case) if the repository is configured to track them\nanyway, to match what \"pull $there\" that uses the default configuration\ndoes.\n\nI am actually even Ok, at least in the long run (like in 3 years), if we\nwere to deprecate the refspecs with colon given on the command line to\n\"pull\" and \"fetch\" altogether [*1*]. The rule will become \"if you are\ngoing to use tracking branches to store what you fetch, you _must_ always\nhave the tracking mapping defined in remote.$there.fetch configuration,\nand the location where one particular branch from the remote is stored is\nalways determined by that mapping.\" It robs us the flexibility to fetch\nmy 'next' and store it to your 'next' branch today and to your 'mext'\nbranch tomorrow, and instead you would need to first fetch and then do an\nexplicit \"git branch mext origin/next\" if you really want to do so, but I\nthink the flexibility outlived its usefulness --- the primary value of\nthese kinds of flexibility is to experiment with various workflows and UI\nconcepts they allow, but I think we have gained enough experience to start\njudging what works (and is useful) and what doesn't (and is Ok to make it\nmuch more cumbersome to make or even impossible to do).\n\n\n[Footnote]\n\n*1* Except perhaps when deleting branches from the remote with \"push\", but\neven there we _could_ force people to do a deleting push separate from\nnormal push and say \"push --delete $there $this $and $that\".\n"},{"id":"125569","messageId":"20091021063008.GA3349@glandium.org","threadId":"21298","inReplyTo":"alpine.LNX.2.00.0910201912390.14365@iabervon.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-10-21T06:30:08Z","receivedAt":"2009-10-21T06:30:08Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Oct 20, 2009 at 07:56:01PM -0400, Daniel Barkalow wrote:\n> On Tue, 20 Oct 2009, Thomas Rast wrote:\n> \n> > Hi all,\n> > \n> > While everyone is busy in two other UI threads, I figured I might as\n> > well toss up another (probably) controversial topic.\n> > \n> > Especially on IRC, we see many people who are some combination of\n> > misunderstanding, misusing or overusing git-pull. I figure this is\n> > the result of several factors, notably\n> > \n> > a) pull/push are not symmetric,\n> \n> In a certain sense they are; they both update the branches local to one \n> repository with the data from the other repository. In this sense, fetch \n> is the oddity in that it doesn't update any repository's own branches, but \n> just the local information about other repositories' branches.\n\nBTW, shouldn't fetch be deprecated in favour of git remote update ?\n(this may require adding some features to git remote update, but you get\nthe idea)\n\nMike\n"},{"id":"125570","messageId":"7v3a5db6ij.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"20091021063008.GA3349@glandium.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T06:33:40Z","receivedAt":"2009-10-21T06:33:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> BTW, shouldn't fetch be deprecated in favour of git remote update ?\n\nWhy? People will then be confused because half of them would expect\n\"remote update\" to somehow affect their working tree, and some others\nwould expect their working tree reset to one of the branches from the\nremote, and it won't solve anything. Oh, and it will irritate people who\nare used to type \"git fetch\", too.\n"},{"id":"125571","messageId":"20091021070622.GA3737@glandium.org","threadId":"21298","inReplyTo":"7v3a5db6ij.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-10-21T07:06:22Z","receivedAt":"2009-10-21T07:06:22Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Oct 20, 2009 at 11:33:40PM -0700, Junio C Hamano wrote:\n> Mike Hommey writes:\n> \n> > BTW, shouldn't fetch be deprecated in favour of git remote update ?\n> \n> Why? People will then be confused because half of them would expect\n> \"remote update\" to somehow affect their working tree, and some others\n> would expect their working tree reset to one of the branches from the\n> remote, and it won't solve anything.\n\nI must be missing the obvious but which one of fetch and remote update\ndoes the above ? I was under the impression that none of them would.\n\n> Oh, and it will irritate people who\n> are used to type \"git fetch\", too.\n\nThat's another problem, but my understanding is that git fetch and git\nremote update are roughly doing the same thing. Having two commands for\nthe same thing is confusing. I kind of like the idea to have one\ncommand, remote, to handle, err, remotes. Also note that I said\ndeprecated, not remove ; that could mean keeping fetch, but pushing the\nuse of remote update for new users.\n\nMike\n"},{"id":"125572","messageId":"7v63a99pok.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"7v3a5db6ij.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T07:22:35Z","receivedAt":"2009-10-21T07:22:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Mike Hommey writes:\n>\n>> BTW, shouldn't fetch be deprecated in favour of git remote update ?\n>\n> Why? People will then be confused because half of them would expect\n> \"remote update\" to somehow affect their working tree, and some others\n> would expect their working tree reset to one of the branches from the\n> remote, and it won't solve anything. Oh, and it will irritate people who\n> are used to type \"git fetch\", too.\n\nI think the above comment needs to be clarified, so that I will not\ndiscourage you or other people who would want to pursue the part I omitted\nfrom my quote too much, which was:\n\n> (this may require adding some features to git remote update, but you get\n> the idea)\n\nNow, I _personally_ think \"git remote update\" was a half-baked UI\nexperiment that failed, but as the maintainer I'll still give it benefit\nof doubt for a bit longer and let interested parties resurrect and perfect\nit, just in case it might turn out to be a good thing. In the rest, when\nI say \"I think\", pretend as if I said _personally_ (i.e. not speaking as\nthe maintainer who already has given up on it).\n\nI think the original \"git remote add\" was a good interface, similar to\n\"git config\", as the management interface to the remote system used by the\neveryday commands \"fetch/pull/push\". The everyday commands use the remote\nnicknames and their associated data stored in the configuration file.\n\nWhile you can edit your configuration file directly to manage the remotes,\nsome people (and recipe book writers) prefer to have a specialized\nmanagement command. \"git remote add\" is such a management interface that\nyou use once and then you can forget about it. Once you get your remote\nconfigured, the everyday commands will use the data in the configuration\nfile, and the commands you interract with your remotes will be these\neveryday commands, not \"git remote\".\n\nSome people thought that throwing everything that does something to remote\nunder \"git remote\" was a good idea, and \"git remote update\" was invented.\nIt is a thin wrapper around \"fetch\" and does what \"fetch\" does. You need\nto understand \"fetch\" (i.e. downloads the history and necessary objects,\nand updates the remote tracking branches, without ever touching the work\ntree) to understand \"git remote update\" anyway, and more importantly, you\nneed to understand what they do not do.\n\nIt is not even a typesaver. \"git fetch\" updates from the default remote,\nso does \"git remote update\". Personally I think the people who invented\n\"git remote update\" were misguided, and that is why I say it was a failed\nUI experiment that failed, but that is hindsight talking [*1*].\n\nAfter reading Björn's excerpts, it was clear to me that the names of the\ncommands have much less to do with the confusion [*2*] than I originally\nfeared [*3*]. As long as the user needs the same kind of understanding of\nwhat the command does, I do not think changing the command name between\n\"git remote update\" vs \"git fetch\" and calling everything that has\nsomething to do with remote repositories \"remote\" would solve anything.\nThe users also need to understand how to make what these commands do an\nintegrated part in a larger workflow they use, so that they know what to\ndo next, which is much more important issue, and at that point the name of\nthe command is secondary---the concepts counts much more.\n\n\"git remote update\" even has a slight downside in the \"push moves from\nhere to there, pull moves from there to here\" sense. If you never have\nseen git, \"git remote update $there\" may look like you are asking git to\nupdate the remote called $there, presumably with what you have. That is\nquite opposite direction from how it actually move things.\n\n\n[Footnote]\n\n*1* The only thing \"git remote update\" does that \"git fetch\" does not is\nthat it can serve as \"fetch from everywhere\" shorthand. But that is\nsomething we could have added to \"git fetch\". So in that sense, I think\nit may make even more sense to deprecate \"remote update\" and teach \"fetch\"\nhow to do that.\n\n*2* Granted, if our \"pull\" were named \"push\", the natural meaning of the\nword \"push\" that moves things from here to there (as opposed to there to\nhere) may even confuse people, but both \"pull\" and \"fetch\" mean moving\nthings from farther to closer (and nothing more in the natural meaning),\nand the confusion expressed in the thread were not of that kind---nobody\nexpected us to do anything that involves moving something we have to the\nremote, but the confusion was about what happens _after_ something was\nmoved from there to here.\n\n*3* In a sense I somehow was hoping that the confusion was only about the\npush/pull asymmetry as some people claimed. If it were, the problem would\nhave been very easy to fix; you just do not let pull affect the work tree.\nBut the confused users were expecting the changes to be reflected to their\nwork trees, and the confusion was about how that is done. Some wanted\ntheir local changes blown away, some wanted their local histories also get\nblown away, some wanted the changes integrated.\n"},{"id":"125575","messageId":"20091021074522.GA13531@coredump.intra.peff.net","threadId":"21298","inReplyTo":"7v63a99pok.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-21T07:45:22Z","receivedAt":"2009-10-21T07:45:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote:\n\n> Some people thought that throwing everything that does something to remote\n> under \"git remote\" was a good idea, and \"git remote update\" was invented.\n> It is a thin wrapper around \"fetch\" and does what \"fetch\" does. You need\n> to understand \"fetch\" (i.e. downloads the history and necessary objects,\n> and updates the remote tracking branches, without ever touching the work\n> tree) to understand \"git remote update\" anyway, and more importantly, you\n> need to understand what they do not do.\n> \n> It is not even a typesaver. \"git fetch\" updates from the default remote,\n> so does \"git remote update\". Personally I think the people who invented\n> \"git remote update\" were misguided, and that is why I say it was a failed\n> UI experiment that failed, but that is hindsight talking [*1*].\n\nDeclaring it a failure depends on what you consider the goal of \"git\nremote update\" to be. I find it very useful as a shorthand for \"fetch\nfrom _all_ remotes\"[1]. Which does save typing over\n\n $ for i in `git remote`; do git fetch $i; done\n\nAnd of course, there is \"git remote\" again, saving us a few keystrokes\nover:\n\n $ git config --get-regexp 'remote..*.url' | cut -d. -f2\n\n[1]: And I think this is a useful operation. When collaborating with\ndevelopers in multiple repositories, it is nice to see an overview of\nwhat all other people are working on. We have other tools to actually\ncompare the refs, but the first step is obviously getting those refs up\nto date locally.\n\n-Peff\n"},{"id":"125577","messageId":"20091021074759.GB13531@coredump.intra.peff.net","threadId":"21298","inReplyTo":"20091021074522.GA13531@coredump.intra.peff.net","subject":"Re: [RFC] pull/fetch rename","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-21T07:47:59Z","receivedAt":"2009-10-21T07:47:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 21, 2009 at 03:45:22AM -0400, Jeff King wrote:\n\n> Declaring it a failure depends on what you consider the goal of \"git\n> remote update\" to be. I find it very useful as a shorthand for \"fetch\n> from _all_ remotes\"[1]. Which does save typing over\n>\n> [...]\n>\n> On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote:\n>\n>> *1* The only thing \"git remote update\" does that \"git fetch\" does not\n>> is that it can serve as \"fetch from everywhere\" shorthand. But that\n>> is something we could have added to \"git fetch\". So in that sense, I\n>> think it may make even more sense to deprecate \"remote update\" and\n>> teach \"fetch\" how to do that.\n\n...and it would probably help if I had read your footnotes before\nresponding.\n\n-Peff\n"},{"id":"125586","messageId":"20091021115740.GA25049@atjola.homenet","threadId":"21298","inReplyTo":"alpine.LNX.2.00.0910202310070.14365@iabervon.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-10-21T11:57:40Z","receivedAt":"2009-10-21T11:57:40Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.10.21 00:22:18 -0400, Daniel Barkalow wrote:\n> On Wed, 21 Oct 2009, Björn Steinbrink wrote:\n> \n> > 3) User expects \"pull\" to update all branch heads that have a configured\n> > upstream\n> > \n> > 08:31 \tdimsuz \thi guys! suppose i'm currently on master. then run git\n> > \t\tfetch. which delivers updates to master and other\n> > \t\tbranches. I don't merge anything, but do checkout some\n> > \t\tbranch (which is not master). Question: will these new\n> > \t\tupdates get into this branch automatically after i check\n> > \t\tit out? question2: will branch master contain those\n> > \t\tupdates when i ckeck it out later?\n> > 08:32 \tCircuitsoft \tdimsuz. After a fetch, no.\n> > 08:33 \tCircuitsoft \tHowever, if you pull, any branches that were set\n> > \t\t\tup as local tracking branches will get updated.\n> > 08:33 \tCircuitsoft \tOtherwise, only remote tracking branches will be\n> > \t\t\tupdated.\n> > \n> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969\n> > (No idea about that one, have seen that once before, but it's definitely\n> > not even remotely as common as the others)\n> \n> I'd guess that's due to having local branches with no local changes, just \n> to avoid detached HEAD, and therefore thinking it's normal to have a bunch \n> of local branches that could be updated without merges. But I'm on a crazy \n> \"everybody really wants detached HEAD and is needlessly scared\" kick, and \n> I'm probably reading too much into it.\n\nJust to clarify: I didn't mean the question (which I didn't really\nunderstand) in this case, but the answer from Circuitsoft (second to\nlast line). But maybe you also meant that? The question confuses me\nenough not to be able to follow.\n\n\n> > 4) User expects \"pull\" to create branches\n> > \n> > 07:25 \tfynn \tHey, I just pulled a branch from remote, and I don't see\n> > \t\tit in \"git branch\"\n> > 07:25 \tdoener \tfynn: if you \"pull\" that means \"fetch this and merge it\n> > \t\tto what I have checked out\"\n> > 07:25 \tfynn \tdoener: hm, I just did \"git pull\" and it showed the new\n> > \t\tbranch\n> > 07:26 \tfynn \tbut I don't see it in my branches...\n> > 07:26 \tfynn \tdoener: should I create that branch as a tracking branch\n> > \t\tfirst?\n> > 07:26 \tdoener \tfynn: you're looking at \"git branch -r\" or \"git branch\n> > \t\t-a\", right?\n> > 07:26 \tfynn \tdoener: yeah, I'm seeing it in origin/foo, but not\n> > \t\tlocal.\n> > 07:26 \tdoener \tfynn: the \"git fetch\" should have created a remote\n> > \t\ttracking branch, as usual, not a local branch head\n> > \t\t(which would be shown by just \"git branch\")\n> > 07:27 \tfynn \tdoener: OK, what should I do to create it locally then?\n> > 07:28 \tdoener \tfynn: just the usual \"git branch foo origin/foo\", or to\n> > \t\tcheckout at the same time: \"git checkout -b foo\n> > \t\torigin/foo\" or \"git checkout -t origin/foo\" (shortcut)\n> > \n> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830\n> > (Note how my \"fetch this and merge it\" is actually inaccurate for just\n> > \"git pull\", there is no \"this\" and that case. I took \"pulled a branch\"\n> > to mean that he did \"git pull \", which wouldn't have\n> > created/update the remote tracking branch [or did patches for that go\n> > in? I lost track...])\n> \n> That sounds like a real converse of \"push\", including creating like-named \n> local branches. Or, perhaps, this is someone expecting that \"pull\" is like \n> \"clone\" in creating an initial local branch with the name and value of a \n> specified remote branch.\n\nReading that one again, I realize that I've still been confused by the\n\"pulled a branch\". What happened was that the user did \"git pull\", which\nran \"git fetch \", which fetched a new branch head and has shown\nthat. At that point, the user (and me) got confused for maybe two reasons:\n\na) He didn't clearly distinguish between the fetch and the merge part.\nThe new branch wasn't pulled, but just fetched. That caused the user to\nthink that he \"pulled the branch\" (wrong terminology), which in term\nconfused me (wrong use-case assumed).\n\nb) He expected local branch heads to be created, instead of remote\ntracking branches. If my memory doesn't play tricks on me, that's\nactually not to be expected from that specific user (I think we told him\nabout remote tracking branches before, and the last part of the\nconversation actually suggests that, too). If I don't forget, I'll try\nto get feedback from him the next time he's around.\n\n\n> > 5) User possibly expecting \"pull\" to be able to act as \"reset --hard\"\n> > \n> > 21:01 \taidan \tWhat do I do about this: html/config/core.php: needs\n> > \t\tupdate\n> > 21:02 \taidan \tgit pull (gives that)\n> > 21:02 \tIlari \taidan: You have uncommitted changes to that file...\n> > 21:15 \taidan \tIlari: how can I just pull master and overwrite any\n> > \t\tchanges?\n> > \n> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130\n> > (I'm not sure about that one, \"overwrite any changes\" might mean \"drop\n> > uncommitted changes and merge\" or \"just get me the remote's state,\n> > dropping my commits and uncommitted changes\". Most of the time I've seen\n> > similar requests, the user wanted the latter).\n> \n> So I think that's a desire for \"git checkout .\" first of all (with the \n> assumption that the content without modifications has to come from \n> somewhere remote). I don't know what's up with people not wanting to save \n> their commits, though.\n\nYou haven't seen the multitude of \"I have merge conflicts and just want\nto take theirs/mine\" requests. That often gets more weird than just\n\"drop my commits\" ;-)\n\n> > 6) User says \"pull\" but probably means \"fetch\"\n> > \n> > 14:08 \tAlien_Freak \tonce I have a clone of a repo I know you can do\n> > \t\t\ta checkout tag but is there anyway to pull just\n> > \t\t\tthe tag?\n> > \n> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664\n> > (There was no answer, thus it's hard to tell, but I guess he wanted\n> > something like:\n> > git init; git fetch --no-tags url tag ; git checkout \n> > At least I'm quite sure he didn't mean \"pull\" as in \"git pull\")\n> \n> I don't know; you can actually do:\n> \n> $ git init; git pull --no-tags tag \n> \n> It updates the master branch and working directory from (nothing) to the \n> fetched tag.\n\nHm, yeah, that works (didn't think of it), but it's a rather special\ncase. Teaching that might lead to misunderstandings about what \"pull\"\ndoes, I think. It would look somewhat like \"fetch + reset --hard\".\n\n> > 8) \"reset --hard\" again\n> > \n> > 20:10 \troger_padactor \ti commited then did a pull how do i get back to\n> > \t\t\tmy commit. the pull over wrote the files\n> > 20:11 \tmerlin83 \troger_padactor: you can't, pull == fetch + hard\n> > \t\t\treset to latest commit\n> > \n> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306\n> > (Someone being told that pull is fetch + reset --hard is actually new to\n> > me. Only saw that as an expectation previously.)\n> \n> That's odd. How could you not notice that it doesn't actually do that, \n> even if you try to get it to?\n\nHm? roger_padactor noticed that \"pull\" changed his files and wants to go\nback. And merlin83 says that that is impossible because pull supposedly\ndoes reset --hard. There's nothing in there (I could see) that suggests\nthat anyone tried to make \"pull\" do \"reset --hard\".\n\nmerlin83 basically made three mistakes, I think:\n1) Assume that roger_padactor was talking about uncommitted changes\n2) Assume that pull is fetch + reset --hard\n3) Assume that you can't undo a reset --hard for committed changes\n\n(OK, 3) isn't actually valid when you consider 1), but 1) is so invalid\nthat I kept 3). After all, \"pull\" would complain about a dirty tree...)\n\n\n> Actually, I wonder if the right formula is update = fetch + checkout. \n> There are a lot of people (IMHO) want \"git fetch origin; git checkout \n> origin/master\", and I think their first idea is \"git update\", but that \n> doesn't exist, and they find \"pull\" as the closest thing.\n\nThat has a precondition that the user is already using a detached HEAD.\nOtherwise that fetch + checkout would likely mean that the get baffled\nwhen they do:\ngit checkout master\ngit update\ngit checkout foo\ngit checkout master\n\nSeeing that \"master\" is out of date \"again\".\n\nI agree though, that users might look for \"git update\" and because it is\nmissing, they just look for the closest thing. Adding Junio's statement\nthat users seem to want recipes instead of flexibility (and seeing\n\"update\" as just \"get me new stuff from upstream\" without meaning any\nspecific method of updating), I think that \"git update\" could be a \"recipe\ncollection\" tool. I'll hack that into my proof-of-concept thing (which\nI hope to have ready for a RFC next week).\n\nBjörn\n"},{"id":"125621","messageId":"alpine.LNX.2.00.0910211203230.14365@iabervon.org","threadId":"21298","inReplyTo":"20091021115740.GA25049@atjola.homenet","subject":"Re: [RFC] pull/fetch rename","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-21T17:12:59Z","receivedAt":"2009-10-21T17:12:59Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 21 Oct 2009, Björn Steinbrink wrote:\n\n> On 2009.10.21 00:22:18 -0400, Daniel Barkalow wrote:\n> > On Wed, 21 Oct 2009, Björn Steinbrink wrote:\n> > \n> > > 3) User expects \"pull\" to update all branch heads that have a configured\n> > > upstream\n> > > \n> > > 08:31 \tdimsuz \thi guys! suppose i'm currently on master. then run git\n> > > \t\tfetch. which delivers updates to master and other\n> > > \t\tbranches. I don't merge anything, but do checkout some\n> > > \t\tbranch (which is not master). Question: will these new\n> > > \t\tupdates get into this branch automatically after i check\n> > > \t\tit out? question2: will branch master contain those\n> > > \t\tupdates when i ckeck it out later?\n> > > 08:32 \tCircuitsoft \tdimsuz. After a fetch, no.\n> > > 08:33 \tCircuitsoft \tHowever, if you pull, any branches that were set\n> > > \t\t\tup as local tracking branches will get updated.\n> > > 08:33 \tCircuitsoft \tOtherwise, only remote tracking branches will be\n> > > \t\t\tupdated.\n> > > \n> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969\n> > > (No idea about that one, have seen that once before, but it's definitely\n> > > not even remotely as common as the others)\n> > \n> > I'd guess that's due to having local branches with no local changes, just \n> > to avoid detached HEAD, and therefore thinking it's normal to have a bunch \n> > of local branches that could be updated without merges. But I'm on a crazy \n> > \"everybody really wants detached HEAD and is needlessly scared\" kick, and \n> > I'm probably reading too much into it.\n> \n> Just to clarify: I didn't mean the question (which I didn't really\n> understand) in this case, but the answer from Circuitsoft (second to\n> last line). But maybe you also meant that? The question confuses me\n> enough not to be able to follow.\n\nYeah. I think that Circuitsoft, and a lot of the people in these \nconversations, have local branches they never commit to, and only update \nwith pull, and only use the --track feature to maintain these branches, \nand may not even ever use \"git pull\" for anything other than to maintain \nthese branches. That would give the impression that \"git pull\" always \nleaves the current branch holding the commit that the remote branch is \nholding (i.e., \"reset --hard\") and the guess that this could apply to \nnon-current branches.\n\nBut these local branches don't actually give the users any benefit, \nbecause they're always the same as the ref in remotes/ unless they're \nout-of-date.\n\n> > > 4) User expects \"pull\" to create branches\n> > > \n> > > 07:25 \tfynn \tHey, I just pulled a branch from remote, and I don't see\n> > > \t\tit in \"git branch\"\n> > > 07:25 \tdoener \tfynn: if you \"pull\" that means \"fetch this and merge it\n> > > \t\tto what I have checked out\"\n> > > 07:25 \tfynn \tdoener: hm, I just did \"git pull\" and it showed the new\n> > > \t\tbranch\n> > > 07:26 \tfynn \tbut I don't see it in my branches...\n> > > 07:26 \tfynn \tdoener: should I create that branch as a tracking branch\n> > > \t\tfirst?\n> > > 07:26 \tdoener \tfynn: you're looking at \"git branch -r\" or \"git branch\n> > > \t\t-a\", right?\n> > > 07:26 \tfynn \tdoener: yeah, I'm seeing it in origin/foo, but not\n> > > \t\tlocal.\n> > > 07:26 \tdoener \tfynn: the \"git fetch\" should have created a remote\n> > > \t\ttracking branch, as usual, not a local branch head\n> > > \t\t(which would be shown by just \"git branch\")\n> > > 07:27 \tfynn \tdoener: OK, what should I do to create it locally then?\n> > > 07:28 \tdoener \tfynn: just the usual \"git branch foo origin/foo\", or to\n> > > \t\tcheckout at the same time: \"git checkout -b foo\n> > > \t\torigin/foo\" or \"git checkout -t origin/foo\" (shortcut)\n> > > \n> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830\n> > > (Note how my \"fetch this and merge it\" is actually inaccurate for just\n> > > \"git pull\", there is no \"this\" and that case. I took \"pulled a branch\"\n> > > to mean that he did \"git pull \", which wouldn't have\n> > > created/update the remote tracking branch [or did patches for that go\n> > > in? I lost track...])\n> > \n> > That sounds like a real converse of \"push\", including creating like-named \n> > local branches. Or, perhaps, this is someone expecting that \"pull\" is like \n> > \"clone\" in creating an initial local branch with the name and value of a \n> > specified remote branch.\n> \n> Reading that one again, I realize that I've still been confused by the\n> \"pulled a branch\". What happened was that the user did \"git pull\", which\n> ran \"git fetch \", which fetched a new branch head and has shown\n> that. At that point, the user (and me) got confused for maybe two reasons:\n> \n> a) He didn't clearly distinguish between the fetch and the merge part.\n> The new branch wasn't pulled, but just fetched. That caused the user to\n> think that he \"pulled the branch\" (wrong terminology), which in term\n> confused me (wrong use-case assumed).\n\nRight; when pull shows a branch, it's the fetching step. But I think that \nshouldn't have been confusing to you; the merging step certainly doesn't \nshow anything interesting.\n\n> b) He expected local branch heads to be created, instead of remote\n> tracking branches. If my memory doesn't play tricks on me, that's\n> actually not to be expected from that specific user (I think we told him\n> about remote tracking branches before, and the last part of the\n> conversation actually suggests that, too). If I don't forget, I'll try\n> to get feedback from him the next time he's around.\n\nHe seems to get the thing about remote tracking branches (he says that got \ncreated); he's fine on the \"pull = fetch + (X)\" portion, but he's got (X) \nwrong, and thinks that creates a local branch.\n\nThat's why I think he may be confused by clone's behavior, because clone \ndoes: (create a repo), fetch something, and create a co-named local \nbranch. If clone were init + pull (wrong, but a reasonable guess), then \nclone - init = fetch + checkout -b; so I think he's not totally lost but \nrather just wrong about what compound operations \"pull\" is.\n\n> > > 5) User possibly expecting \"pull\" to be able to act as \"reset --hard\"\n> > > \n> > > 21:01 \taidan \tWhat do I do about this: html/config/core.php: needs\n> > > \t\tupdate\n> > > 21:02 \taidan \tgit pull (gives that)\n> > > 21:02 \tIlari \taidan: You have uncommitted changes to that file...\n> > > 21:15 \taidan \tIlari: how can I just pull master and overwrite any\n> > > \t\tchanges?\n> > > \n> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130\n> > > (I'm not sure about that one, \"overwrite any changes\" might mean \"drop\n> > > uncommitted changes and merge\" or \"just get me the remote's state,\n> > > dropping my commits and uncommitted changes\". Most of the time I've seen\n> > > similar requests, the user wanted the latter).\n> > \n> > So I think that's a desire for \"git checkout .\" first of all (with the \n> > assumption that the content without modifications has to come from \n> > somewhere remote). I don't know what's up with people not wanting to save \n> > their commits, though.\n> \n> You haven't seen the multitude of \"I have merge conflicts and just want\n> to take theirs/mine\" requests. That often gets more weird than just\n> \"drop my commits\" ;-)\n\nAh, okay; I tend to think of those as content-focused, rather than \nhistory-focused. Like, I think people often run into: \"I reformatted files \nA and B and made important changes to file A; someone else made important \nchanges to file B; I get a awful merge conflict in file B.\" I bet it's \ncommon to want to keep your commit history, but throw away their \nconflicting changes in the resulting content.\n\nThere's also the occasional case where the right solution is to rename a \nbranch to \"things-that-seemed-like-a-good-idea-at-the-time\", create a new \nbranch from upstream with the old name, and never speak of it again.\n\nBut this is all a different topic.\n\n> > > 6) User says \"pull\" but probably means \"fetch\"\n> > > \n> > > 14:08 \tAlien_Freak \tonce I have a clone of a repo I know you can do\n> > > \t\t\ta checkout tag but is there anyway to pull just\n> > > \t\t\tthe tag?\n> > > \n> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664\n> > > (There was no answer, thus it's hard to tell, but I guess he wanted\n> > > something like:\n> > > git init; git fetch --no-tags url tag ; git checkout \n> > > At least I'm quite sure he didn't mean \"pull\" as in \"git pull\")\n> > \n> > I don't know; you can actually do:\n> > \n> > $ git init; git pull --no-tags tag \n> > \n> > It updates the master branch and working directory from (nothing) to the \n> > fetched tag.\n> \n> Hm, yeah, that works (didn't think of it), but it's a rather special\n> case. Teaching that might lead to misunderstandings about what \"pull\"\n> does, I think. It would look somewhat like \"fetch + reset --hard\".\n\nWell, \"merge\" looks like \"reset --hard\" any time it's a fast forward.\n\nI don't think this is a good thing to teach, but if the answer to what the \nuser wants to do when saying \"How can I just pull a tag in a single \ncommand\" is \"pull tag \", it's hard to say that's a misuse of the \nterm.\n\n> > > 8) \"reset --hard\" again\n> > > \n> > > 20:10 \troger_padactor \ti commited then did a pull how do i get back to\n> > > \t\t\tmy commit. the pull over wrote the files\n> > > 20:11 \tmerlin83 \troger_padactor: you can't, pull == fetch + hard\n> > > \t\t\treset to latest commit\n> > > \n> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306\n> > > (Someone being told that pull is fetch + reset --hard is actually new to\n> > > me. Only saw that as an expectation previously.)\n> > \n> > That's odd. How could you not notice that it doesn't actually do that, \n> > even if you try to get it to?\n> \n> Hm? roger_padactor noticed that \"pull\" changed his files and wants to go\n> back. And merlin83 says that that is impossible because pull supposedly\n> does reset --hard. There's nothing in there (I could see) that suggests\n> that anyone tried to make \"pull\" do \"reset --hard\".\n\nI'm surprised that merlin83 can think that pull = fetch + reset --hard; \npeople often seem to try to do fetch + reset --hard with pull, but it \ndoesn't actually work for them. \n\n> merlin83 basically made three mistakes, I think:\n> 1) Assume that roger_padactor was talking about uncommitted changes\n> 2) Assume that pull is fetch + reset --hard\n> 3) Assume that you can't undo a reset --hard for committed changes\n> \n> (OK, 3) isn't actually valid when you consider 1), but 1) is so invalid\n> that I kept 3). After all, \"pull\" would complain about a dirty tree...)\n> \n> \n> > Actually, I wonder if the right formula is update = fetch + checkout. \n> > There are a lot of people (IMHO) want \"git fetch origin; git checkout \n> > origin/master\", and I think their first idea is \"git update\", but that \n> > doesn't exist, and they find \"pull\" as the closest thing.\n> \n> That has a precondition that the user is already using a detached HEAD.\n> Otherwise that fetch + checkout would likely mean that the get baffled\n> when they do:\n> git checkout master\n> git update\n> git checkout foo\n> git checkout master\n> \n> Seeing that \"master\" is out of date \"again\".\n\nAgreed; I think:\n\n$ git checkout master\n$ git update\nYou are on a local branch. Local branches are under your complete control, \nso there is nowhere to get updates from. If you would like to merge remote \ncommits into your local branch, you could use \"git pull\". If you would \nrather look at a remote branch, you could use \"git checkout \".\n\nOf course, without this message:\n\n$ git checkout master\n$ git update\n\nwould be the same as:\n\n$ git chekcout master\n$ git fetch\n$ git checkout master\n\nwhich would already not show any changes. (I'm thinking of the target of \nthe checkout in update-with-no-target as being whatever you typed last \ntime, and the fetch being whatever fetch normally updates that target.)\n\nPersonally, I often run:\n\n$ git fetch; git checkout origin/next\n\nThis suggests that this is a useful combination of commands.\n\n> I agree though, that users might look for \"git update\" and because it is\n> missing, they just look for the closest thing. Adding Junio's statement\n> that users seem to want recipes instead of flexibility (and seeing\n> \"update\" as just \"get me new stuff from upstream\" without meaning any\n> specific method of updating), I think that \"git update\" could be a \"recipe\n> collection\" tool. I'll hack that into my proof-of-concept thing (which\n> I hope to have ready for a RFC next week).\n\nI'll be interested to see that.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"125623","messageId":"20091021171902.GA27495@localhost","threadId":"21298","inReplyTo":"7vk4ypb71j.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2009-10-21T17:19:02Z","receivedAt":"2009-10-21T17:19:02Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:\n\n> For example, I am in favor of deprecating the \"pull $there $src:$dst\"\n> notation. Before we standardized on the separate remote layout, it was\n> sometimes handy to be able to use $dst that is a local branch, but these\n> days, especially when repository $there has remote.$there.fetch mapping\n> configured so that we can compute from $src what remote tracking branch we\n> should store the fetched commit, the flexibility is more confusing than it\n> is useful.\n\nI emphatically agree. I was always uncomfortable with the refspec syntax,\nbecause it is too flexible. Why would I ever want to access branch refs\nother than refs/heads/ on the remote, and why would I ever want to write\ndirectly to the local refs/heads/ namespace (in a non-bare repo), as opposed\nto refs/remotes/? Unless he wants to do something unusual, the user\nshould not be confronted with questions like that.\n\nClemens\n"},{"id":"125622","messageId":"20091021172123.GB27495@localhost","threadId":"21298","inReplyTo":"7vk4ypb71j.fsf@alter.siamese.dyndns.org","subject":"[PATCH] modernize fetch/merge/pull examples","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2009-10-21T17:21:23Z","receivedAt":"2009-10-21T17:21:23Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"The \"git pull\" documentation has examples which follow an outdated\nstyle. Update the examples to use \"git merge\" where appropriate and\nmove the examples to the corresponding manpages.\n\nFurthermore,\n\n o show that pull is equivalent to fetch and merge, which is still a\n frequently asked question,\n\n o explain the default fetch refspec.\n\nSigned-off-by: Clemens Buchacher \n---\nOn Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:\n\n> For example, I am in favor of deprecating the \"pull $there $src:$dst\"\n> notation. \n\nA first step in that direction.\n\nClemens\n\n Documentation/git-fetch.txt | 29 +++++++++++++++++++++++++\n Documentation/git-merge.txt | 33 +++++++++++++++++++++++++++++\n Documentation/git-pull.txt | 49 +++---------------------------------------\n 3 files changed, 66 insertions(+), 45 deletions(-)\n\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex d3164c5..c76077d 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -37,6 +37,35 @@ include::pull-fetch-param.txt[]\n \n include::urls-remotes.txt[]\n \n+\n+EXAMPLES\n+--------\n+\n+* Update the remote-tracking branches:\n++\n+------------------------------------------------\n+$ git fetch origin\n+------------------------------------------------\n++\n+The above command copies all branches from the remote refs/heads/\n+namespace and stores them to the local refs/remotes/origin/ namespace,\n+unless the branch..fetch option is used to specify a non-default\n+refspec.\n+\n+* Using refspecs explicitly:\n++\n+------------------------------------------------\n+$ git fetch origin +pu:pu maint:tmp\n+------------------------------------------------\n++\n+This updates (or creates, as necessary) branches `pu` and `tmp` in\n+the local repository by fetching from the branches (respectively)\n+`pu` and `maint` from the remote repository.\n++\n+The `pu` branch will be updated even if it is does not fast-forward;\n+the others will not be.\n+\n+\n SEE ALSO\n --------\n linkgit:git-pull[1]\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex d05f324..2a41d62 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -212,6 +212,39 @@ You can work through the conflict with a number of tools:\n common ancestor, 'git show :2:filename' shows the HEAD\n version and 'git show :3:filename' shows the remote version.\n \n+\n+EXAMPLES\n+--------\n+\n+* Bundle branches `fixes` and `enhancements` on top of\n+ the current branch, making an Octopus merge:\n++\n+------------------------------------------------\n+$ git merge fixes enhancements\n+------------------------------------------------\n+\n+* Merge branch `obsolete` into the current branch, using `ours`\n+ merge strategy:\n++\n+------------------------------------------------\n+$ git merge -s ours obsolete\n+------------------------------------------------\n+\n+* Merge branch `maint` into the current branch, but do not make\n+ a commit automatically:\n++\n+------------------------------------------------\n+$ git merge --no-commit maint\n+------------------------------------------------\n++\n+This can be used when you want to include further changes to the\n+merge, or want to write your own merge commit message.\n++\n+You should refrain from abusing this option to sneak substantial\n+changes into a merge commit. Small fixups like bumping\n+release/version name would be acceptable.\n+\n+\n SEE ALSO\n --------\n linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 7578623..de2bcd6 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -131,54 +131,13 @@ $ git pull origin next\n ------------------------------------------------\n +\n This leaves a copy of `next` temporarily in FETCH_HEAD, but\n-does not update any remote-tracking branches.\n-\n-* Bundle local branch `fixes` and `enhancements` on top of\n- the current branch, making an Octopus merge:\n-+\n-------------------------------------------------\n-$ git pull . fixes enhancements\n-------------------------------------------------\n-+\n-This `git pull .` syntax is equivalent to `git merge`.\n-\n-* Merge local branch `obsolete` into the current branch, using `ours`\n- merge strategy:\n-+\n-------------------------------------------------\n-$ git pull -s ours . obsolete\n-------------------------------------------------\n-\n-* Merge local branch `maint` into the current branch, but do not make\n- a commit automatically:\n+does not update any remote-tracking branches. Using remote-tracking\n+branches, the same can be done by invoking fetch and merge:\n +\n ------------------------------------------------\n-$ git pull --no-commit . maint\n+$ git fetch origin\n+$ git merge origin/next\n ------------------------------------------------\n-+\n-This can be used when you want to include further changes to the\n-merge, or want to write your own merge commit message.\n-+\n-You should refrain from abusing this option to sneak substantial\n-changes into a merge commit. Small fixups like bumping\n-release/version name would be acceptable.\n-\n-* Command line pull of multiple branches from one repository:\n-+\n-------------------------------------------------\n-$ git checkout master\n-$ git fetch origin +pu:pu maint:tmp\n-$ git pull . tmp\n-------------------------------------------------\n-+\n-This updates (or creates, as necessary) branches `pu` and `tmp` in\n-the local repository by fetching from the branches (respectively)\n-`pu` and `maint` from the remote repository.\n-+\n-The `pu` branch will be updated even if it is does not fast-forward;\n-the others will not be.\n-+\n-The final command then merges the newly fetched `tmp` into master.\n \n \n If you tried a pull which resulted in a complex conflicts and\n-- \n1.6.5.1\n"},{"id":"125652","messageId":"7v3a5c2zrr.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"20091021172123.GB27495@localhost","subject":"Re: [PATCH] modernize fetch/merge/pull examples","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T21:38:48Z","receivedAt":"2009-10-21T21:38:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Clemens Buchacher writes:\n\n> The \"git pull\" documentation has examples which follow an outdated\n> style. Update the examples to use \"git merge\" where appropriate and\n> move the examples to the corresponding manpages.\n\nMakes sense, although I did some minor rewording.\n\nI noticed something related while reading this (the issue does not affect\nthe validity of this patch).\n\n> +* Merge branch `maint` into the current branch, but do not make\n> + a commit automatically:\n> ++\n> +------------------------------------------------\n> +$ git merge --no-commit maint\n> +------------------------------------------------\n> ++\n> +This can be used when you want to include further changes to the\n> +merge, or want to write your own merge commit message.\n\nWhen you are up to date with maint this would be a no-op, and when you are\nstrictly behind maint it will succeed without creating a new commit.\n\nI have two possible approaches to fix this issue.\n"},{"id":"125653","messageId":"7vpr8g1l2a.fsf_-_@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"7v3a5c2zrr.fsf@alter.siamese.dyndns.org","subject":"[RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T21:41:49Z","receivedAt":"2009-10-21T21:41:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Traditionally \"git merge --no-commit\" meant just that: do not create a new\ncommit even when a merge succeeds. But this leads to confusion when the\nmerged commit is a descendant of the current commit, in which case we\nsucceed the merge by fast-forwarding and without creating a new commit.\nAlso when the merged commit is already a part of the history, we succeeded\nwithout doing anything.\n\nError out when --no-commit is given but the merge would result in a\nfast-forward or an up-to-date.\n\nSigned-off-by: Junio C Hamano \n---\n\n * This is the first alternative. I think it makes more sense than the\n other one, but I am unsure, as I obviously do not get confused when\n --no-commit becomes no-op due to a fast-forward nor an up-to-date and\n am rather happy with the current behaviour.\n\n builtin-merge.c | 11 +++++++++++\n 1 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-merge.c b/builtin-merge.c\nindex b6b8428..4cfdf75 100644\n--- a/builtin-merge.c\n+++ b/builtin-merge.c\n@@ -829,6 +829,12 @@ static int evaluate_result(void)\n \treturn cnt;\n }\n \n+static void check_no_commit(const char *msg)\n+{\n+\tif (!option_commit)\n+\t\tdie(\"The merge will %s but --no-commit was given.\", msg);\n+}\n+\n int cmd_merge(int argc, const char **argv, const char *prefix)\n {\n \tunsigned char result_tree[20];\n@@ -996,6 +1002,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t * If head can reach all the merge then we are up to date.\n \t\t * but first the most common case of merging one remote.\n \t\t */\n+\t\tcheck_no_commit(\"be a no-op because you are up-to-date\");\n \t\tfinish_up_to_date(\"Already up-to-date.\");\n \t\treturn 0;\n \t} else if (allow_fast_forward && !remoteheads->next &&\n@@ -1006,6 +1013,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tstruct object *o;\n \t\tchar hex[41];\n \n+\t\tif (allow_fast_forward)\n+\t\t\tcheck_no_commit(\"fast forward\");\n+\n \t\tstrcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));\n \n \t\tif (verbosity >= 0)\n@@ -1074,6 +1084,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t\t}\n \t\t}\n \t\tif (up_to_date) {\n+\t\t\tcheck_no_commit(\"fast forward\");\n \t\t\tfinish_up_to_date(\"Already up-to-date. Yeeah!\");\n \t\t\treturn 0;\n \t\t}\n-- \n1.6.5.1.107.gba912\n"},{"id":"125655","messageId":"7viqe81ktx.fsf_-_@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"7v3a5c2zrr.fsf@alter.siamese.dyndns.org","subject":"[PATCH] git-merge: imply --no-ff when --no-commit is given","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T21:46:50Z","receivedAt":"2009-10-21T21:46:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Traditionally \"git merge --no-commit\" meant just that: do not create a new\ncommit even when a merge succeeds. But this leads to confusion when the\nmerged commit is a descendant of the current commit, in which case we\nsucceed the merge by fast-forwarding and without creating a new commit.\n\nMake --no-commit imply --no-ff; --no-commit is a request by the user to\ntweak the resulting merge and it is clear indication that the user wants\nto have a merge, even if it is an extra one, to futz with.\n\nThere is a test that relies on --no-commit silently fast forwarding; that\nis obviously broken by this change.\n\nSigned-off-by: Junio C Hamano \n---\n\n * This is another possibility, which I think is worse than the other one\n in practice but the justification sounds more respectable.\n\n Unlike the other one, this will still make --no-commit a no-op when you\n are already up-to-date. As I do not think --no-ff makes much sense in\n my own workflow (either here or dayjob) it is not exactly my itch, but\n I suspect that people who wanted to have --no-ff may want to create an\n extra commit even in such a case; it may be a bug to allow up-to-date\n when --no-ff is given. Yes, it would make the --no-ff even more insane\n than it already is, but I suspect it would be more consistent with the\n original reasoning of wanting to have the option in the first place,\n namely, to leave the trace of the fact that a \"merge\" was done at that\n point in the history.\n\n builtin-merge.c | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-merge.c b/builtin-merge.c\nindex b6b8428..fa86799 100644\n--- a/builtin-merge.c\n+++ b/builtin-merge.c\n@@ -874,6 +874,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\toption_commit = 0;\n \t}\n \n+\tif (!option_commit)\n+\t\tallow_fast_forward = 0;\n+\n \tif (!argc)\n \t\tusage_with_options(builtin_merge_usage,\n \t\t\tbuiltin_merge_options);\n-- \n1.6.5.1.107.gba912\n"},{"id":"125677","messageId":"20091022063502.GA8311@localhost","threadId":"21298","inReplyTo":"7viqe81ktx.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-merge: imply --no-ff when --no-commit is given","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2009-10-22T06:35:02Z","receivedAt":"2009-10-22T06:35:02Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Wed, Oct 21, 2009 at 02:46:50PM -0700, Junio C Hamano wrote:\n\n> Make --no-commit imply --no-ff; --no-commit is a request by the user to\n> tweak the resulting merge and it is clear indication that the user wants\n> to have a merge, even if it is an extra one, to futz with.\n\nI think --no-commit makes sense in case of a real merge, because a 3-way\ndiff can help fix any semantic errors. Apart from that, one can simply do a\nregular merge and --amend it later.\n\nIn case of a fast-forward merge, there is not going to be a 3-way diff\nanyways. So it's pointless to use --no-commit in this case.\n\nI'm therefore in favor of your other proposal, even though it may be\nconfusing to users who don't understand the difference between n-way and\nfast-forward merge. But that's something they will have to learn.\n\nAnd --no-ff can always be used explicitly.\n\nClemens\n"},{"id":"125692","messageId":"200910221051.26336.trast@student.ethz.ch","threadId":"21298","inReplyTo":"20091021172123.GB27495@localhost","subject":"Re: [PATCH] modernize fetch/merge/pull examples","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-22T08:51:23Z","receivedAt":"2009-10-22T08:51:23Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Clemens Buchacher wrote:\n> On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:\n> \n> > For example, I am in favor of deprecating the \"pull $there $src:$dst\"\n> > notation. \n> \n> A first step in that direction.\n\nI think this is a good change independently of the deprecation.\n\n> +------------------------------------------------\n> +$ git fetch origin +pu:pu maint:tmp\n> +------------------------------------------------\n[...]\n> +The `pu` branch will be updated even if it is does not fast-forward;\n> +the others will not be.\n\nI think to a new user it is not immediately clear if this means \"will\nnot be updated, period\" or \"will not be updated if ...\". How about\n\n The `pu` branch will always be updated; the `tmp` branch only if it\n is a fast-forward update.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"125695","messageId":"200910221148.28335.trast@student.ethz.ch","threadId":"21298","inReplyTo":"7vk4ypb71j.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] pull/fetch rename","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-22T09:48:26Z","receivedAt":"2009-10-22T09:48:26Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> Björn Steinbrink writes:\n> \n> > So that's ten days of #git. I left out a bunch of duplications (most\n> > were \"pull == fetch\", \"pull == update\" and \"pull to update\n> > non-checked-out branch\").\n> \n> Interesting; this shows that people who do not understand what \"pull\" does\n> expect different behaviour from \"pull\", use the word \"pull\" to express\n> what they want to happen, expect other people interpret the word to mean\n> the way they think it does. At the same time, judging from different\n> behaviour expected by these people, push/pull asymmetry does not seem to\n> have much to do with the confusion.\n\nThis of course is where our conclusions differ. I haven't counted\nthem, but Björn (thanks again for the excellent survey) points out\nthat most duplicates are confusion with fetch, (imagined) update or\n\"update to not checked out branch\".\n\nPull is none of these, but if it was (current) fetch, at least the\nfirst group of people would have had the right idea of what it does.\n\n> I am actually even Ok, at least in the long run (like in 3 years), if we\n> were to deprecate the refspecs with colon given on the command line to\n> \"pull\" and \"fetch\" altogether [*1*].\n\nAs an aside, there are actually some use-cases, e.g., to grab the\ngit-svn refs from a freshly cloned repository you would run:\n\n git fetch origin refs/remotes/*:refs/remotes/*\n\n(and then 'git svn init' etc.) I've also had some weird requests on\nIRC that could be solved by clever (and of course dangerous) use of\n'git fetch . glob:otherglob'.\n\nHiding that power behind an option could be a good idea though.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"125697","messageId":"20091022192145.6117@nanako3.lavabit.com","threadId":"21298","inReplyTo":"7vpr8g1l2a.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-10-22T10:21:45Z","receivedAt":"2009-10-22T10:21:45Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano \n\n> Traditionally \"git merge --no-commit\" meant just that: do not create a new\n> commit even when a merge succeeds. But this leads to confusion when the\n> merged commit is a descendant of the current commit, in which case we\n> succeed the merge by fast-forwarding and without creating a new commit.\n> Also when the merged commit is already a part of the history, we succeeded\n> without doing anything.\n>\n> Error out when --no-commit is given but the merge would result in a\n> fast-forward or an up-to-date.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n>\n> * This is the first alternative. I think it makes more sense than the\n> other one, but I am unsure, as I obviously do not get confused when\n> --no-commit becomes no-op due to a fast-forward nor an up-to-date and\n> am rather happy with the current behaviour.\n\nI think this is good (but I am saying this only from your \ndescription without understanding the updated code), but \nthe change breaks --squash to merge a branch, doesn't it?\n\n % git checkout feature # from your master branch\n % work; git commit; work; git commit\n % git checkout master # go back to your master branch\n % git merge --squash feature\n\nThis is a useful way to clean up changes that were built\nin small steps that turned out to be worth only a commit.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"125752","messageId":"7vaazjf4lg.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"20091022192145.6117@nanako3.lavabit.com","subject":"Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-22T22:26:03Z","receivedAt":"2009-10-22T22:26:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> the change breaks --squash to merge a branch, doesn't it?\n>\n> % git checkout feature # from your master branch\n> % work; git commit; work; git commit\n> % git checkout master # go back to your master branch\n> % git merge --squash feature\n>\n> This is a useful way to clean up changes that were built\n> in small steps that turned out to be worth only a commit.\n\nIncidentally we seemed to have seen an end user request for exactly this\nworkflow.\n\nA reroll has been queued, as below, with an update to a test script that\nexpects --no-commit to be a no-op for fast-forward.\n\n-- >8 --\n\nTraditionally \"git merge --no-commit\" meant just that: do not create a new\ncommit even when a merge succeeds. But this leads to confusion when the\nmerged commit is a descendant of the current commit, in which case we\nsucceed the merge by fast-forwarding and without creating a new commit.\n\nAlso when the merged commit is already a part of the history, we succeeded\nwithout doing anything.\n\nError out when --no-commit is given but the merge would result in a\nfast-forward or an up-to-date.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-merge.c | 11 +++++++++++\n t/t7600-merge.sh | 4 +---\n 2 files changed, 12 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-merge.c b/builtin-merge.c\nindex b6b8428..2149aed 100644\n--- a/builtin-merge.c\n+++ b/builtin-merge.c\n@@ -829,6 +829,12 @@ static int evaluate_result(void)\n \treturn cnt;\n }\n \n+static void check_no_commit(const char *msg)\n+{\n+\tif (!option_commit)\n+\t\tdie(\"The merge will %s but --no-commit was given.\", msg);\n+}\n+\n int cmd_merge(int argc, const char **argv, const char *prefix)\n {\n \tunsigned char result_tree[20];\n@@ -996,6 +1002,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t * If head can reach all the merge then we are up to date.\n \t\t * but first the most common case of merging one remote.\n \t\t */\n+\t\tcheck_no_commit(\"be a no-op because you are up-to-date\");\n \t\tfinish_up_to_date(\"Already up-to-date.\");\n \t\treturn 0;\n \t} else if (allow_fast_forward && !remoteheads->next &&\n@@ -1006,6 +1013,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tstruct object *o;\n \t\tchar hex[41];\n \n+\t\tif (allow_fast_forward && !squash)\n+\t\t\tcheck_no_commit(\"fast forward\");\n+\n \t\tstrcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));\n \n \t\tif (verbosity >= 0)\n@@ -1074,6 +1084,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t\t}\n \t\t}\n \t\tif (up_to_date) {\n+\t\t\tcheck_no_commit(\"be a no-op because you are up-to-date\");\n \t\t\tfinish_up_to_date(\"Already up-to-date. Yeeah!\");\n \t\t\treturn 0;\n \t\t}\ndiff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\nindex e5b210b..86b0537 100755\n--- a/t/t7600-merge.sh\n+++ b/t/t7600-merge.sh\n@@ -265,9 +265,7 @@ test_debug 'gitk --all'\n \n test_expect_success 'merge c0 with c1 (no-commit)' '\n \tgit reset --hard c0 &&\n-\tgit merge --no-commit c1 &&\n-\tverify_merge file result.1 &&\n-\tverify_head $c1\n+\ttest_must_fail git merge --no-commit c1\n '\n \n test_debug 'gitk --all'\n-- \n1.6.5.1.124.g746fb6\n"},{"id":"125823","messageId":"7v4opp9udj.fsf@alter.siamese.dyndns.org","threadId":"21298","inReplyTo":"20091021074522.GA13531@coredump.intra.peff.net","subject":"Re: [RFC] pull/fetch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-24T06:30:16Z","receivedAt":"2009-10-24T06:30:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote:\n>\n>> It is not even a typesaver. \"git fetch\" updates from the default remote,\n>> so does \"git remote update\". Personally I think the people who invented\n>> \"git remote update\" were misguided, and that is why I say it was a failed\n>> UI experiment that failed, but that is hindsight talking [*1*].\n>\n> Declaring it a failure depends on what you consider the goal of \"git\n> remote update\" to be. I find it very useful as a shorthand for \"fetch\n> from _all_ remotes\"[1]. Which does save typing over\n>\n> $ for i in `git remote`; do git fetch $i; done\n\nYou've since read my footnote about \"git fetch \", so I do not think\nthis part is controversial anymore.\n\n> And of course, there is \"git remote\" again, saving us a few keystrokes\n> over:\n>\n> $ git config --get-regexp 'remote..*.url' | cut -d. -f2\n\nAnd as you may have already realized by now, I was saying two things.\n\n (1) \"git remote\" in general is a good management interface for remote\n nicknames and attributes attached to them, in the similar spirit as\n \"git config\" is a good management interface for the underlying\n configuration files.\n\n (2) \"git remote update\" is a misguided UI expariment that failed.\n\nSo there is no disagreement between us on the \"and of course\" part,\neither.\n"}]}