{"thread":{"id":"18329","subject":"Re: fetch and pull","startedAt":"2009-03-16T19:00:46Z","lastAt":"2009-03-18T16:50:02Z","messageCount":19,"participants":["John Dlugosz","Jay Soffian","Sverre Rabbelier","Jeff King","Nanako Shiraishi","Björn Steinbrink","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108109","messageId":"450196A1AAAE4B42A00A8B27A59278E70A2AEF9A@EXCHANGE.trad.tradestation.com","threadId":"18329","inReplyTo":null,"subject":"Re: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-16T19:00:46Z","receivedAt":"2009-03-16T19:00:46Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"=== Re: ===\n> So, after inspecting the changes, how do you fast-forward your local\ndev\n> to sync up with origin/dev?\n\n$ git push . origin/dev dev\n=== end ===\n\nThat did not work. It just reports \"everything up to date\". If I\nunderstand the point of what it does correctly, I think\n\n\t$ git push . +origin/dev:dev\n\nis correct.\n\n\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"108115","messageId":"76718490903161303h45e47a8co83159e32ae749352@mail.gmail.com","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A2AEF9A@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-16T20:03:59Z","receivedAt":"2009-03-16T20:03:59Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 16, 2009 at 3:00 PM, John Dlugosz wrote:\n> === Re: ===\n>> So, after inspecting the changes, how do you fast-forward your local\n> dev\n>> to sync up with origin/dev?\n>\n> $ git push . origin/dev dev\n> === end ===\n>\n> That did not work.  It just reports \"everything up to date\".  If I\n> understand the point of what it does correctly, I think\n>\n>        $ git push . +origin/dev:dev\n>\n> is correct.\n\nYou very likely do not want the '+' at the start:\n\n$ git push . origin/dev:dev\n\nj.\n"},{"id":"108135","messageId":"450196A1AAAE4B42A00A8B27A59278E70A2AF023@EXCHANGE.trad.tradestation.com","threadId":"18329","inReplyTo":"76718490903161303h45e47a8co83159e32ae749352@mail.gmail.com","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-16T20:39:41Z","receivedAt":"2009-03-16T20:39:41Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"=== Re: ===\nYou very likely do not want the '+' at the start:\n\n$ git push . origin/dev:dev\n\nj.\n\n=== end ===\n\nYes, I do. If the central repository changed dev in some way other than a fast-forward, or if you really messed up your local dev, it still needs to be repointed.\n\nRemember the overall flow: first fetch (not pull) and then inspect the difference between your dev and origin/dev. Then, change your dev to match.\n\n--John\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"108136","messageId":"fabb9a1e0903161343v458dec59oaae92794a367888c@mail.gmail.com","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A2AF023@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-03-16T20:43:47Z","receivedAt":"2009-03-16T20:43:47Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Mar 16, 2009 at 21:39, John Dlugosz wrote:\n> PT09IFJlOiA9PT0NCllvdSB2ZXJ5IGxpa2VseSBkbyBub3Qgd2FudCB0aGUg\n\nForgot to turn off encryption?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"108150","messageId":"76718490903161514ubbdc948o1a0251212fe65fea@mail.gmail.com","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A2AF023@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-16T22:14:48Z","receivedAt":"2009-03-16T22:14:48Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 16, 2009 at 4:39 PM, John Dlugosz wrote:\n> Yes, I do.  If the central repository changed dev in some way other than a fast-forward, or if you really messed up your local dev, it still needs to be repointed.\n>\n> Remember the overall flow:  first fetch (not pull) and then inspect the difference between your dev and origin/dev.  Then, change your dev to match.\n\nLet me illustrate why this is still probably wrong. I have a clone of\ngit://git.kernel.org/pub/scm/git/git.git. It has the following remote\ntracking branches:\n\n$ git branch -r\n origin/html\n origin/maint\n origin/man\n origin/master\n origin/next\n origin/pu\n origin/todo\n\norigin/master is never reset. origin/pu resets often. When I want to\nwork on git, I typically create a branch from origin/master. In this\ncase, I would almost never want to reset that branch. So I'd typically\ndo:\n\n$ git checkout -b topic origin/master\n$ edit, commit, edit, commit...\n$ git fetch\n$ git log origin/master..topic\n$ git rebase origin/master\n\nRarely, I'll base a topic on origin/pu. And origin/pu might get reset.\nBut even if it were, I wouldn't want to blindly reset my local branch\nto match, thus losing my local changes. Instead I'd do this:\n\n$ git checkout -b pu-topic origin/pu\n$ git tag pu-topic-base # handy when origin/pu is reset\n$ edit, commit, edit, commit\n$ git fetch\ndrat, origin/pu was reset\n$ git rebase --onto origin/pu pu-topic-base\n\nAnd in the rare circumstance that I really do want to reset a local\nbranch, I'd do this:\n\n$ git checkout dev\nexamine, make sure I really want to reset\n$ git reset --hard origin/dev\n\nI can't really think of a good reason I'd want to reset a local branch\nwhich I haven't checked out.\n\nj.\n"},{"id":"108154","messageId":"450196A1AAAE4B42A00A8B27A59278E70A2AF0A9@EXCHANGE.trad.tradestation.com","threadId":"18329","inReplyTo":"76718490903161514ubbdc948o1a0251212fe65fea@mail.gmail.com","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-16T22:33:59Z","receivedAt":"2009-03-16T22:33:59Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> I can't really think of a good reason I'd want to reset a local branch\n> which I haven't checked out.\n> \n> j.\n\nI think the difference is because you mail in your changes to master, and I'm having developers cooperate in advancing that branch. The only thing I need a local copy of dev for is to checkout during the \"work completed\" phase, in which case the topic's result is added to the top of dev for all to see, either as a single amalgamated checkin or a non-ff merge.\n\nCan you suggest a better way of doing that, where \"better\" means minimizing the number of cookbook incantations to learn?\n\nIf, during that procedure, the instruction to\n\tgit checkout dev\nwere replaced by one that checks out the remote and creates the local at that time (what is the argument?), then after pushing the result, delete the local dev. \n\nKeeping the local dev around has the advantage of being able to see what changes have taken place without having to be implicit by eyeballing where your topics branch off from, and makes it clear what you've read/understood already even if you are not going to rebase your topic.\n\n--John\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"108162","messageId":"76718490903161709v6d8d09f6k17d2fe1a5e56fb03@mail.gmail.com","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A2AF0A9@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-17T00:09:31Z","receivedAt":"2009-03-17T00:09:31Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 16, 2009 at 6:33 PM, John Dlugosz wrote:\n\n> I think the difference is because you mail in your changes to master,\n> and I'm having developers cooperate in advancing that branch. The only\n> thing I need a local copy of dev for is to checkout during the \"work\n> completed\" phase, in which case the topic's result is added to the top\n> of dev for all to see, either as a single amalgamated checkin or a\n> non-ff merge.\n\nWhy is the topic a non-ff merge? Here's a normal non-email workflow:\n\n$ git clone git://central/repo.git\n$ cd repo\n$ edit, commit, edit, commit, looks good\n$ git fetch origin\n$ git log -p master..origin/master # (1)\n$ git merge origin/master\n$ compile, test, etc\n$ git push origin master # (2)\n\n(1) inspect changes in origin/master, make sure you want to merge\n(2) this fast-forwards git://central/repo.git/refs/heads/master from\n local master\n\nOr, if you prefer topic branches:\n\n$ git clone git://central/repo.git\n$ cd repo\n$ git checkout -b topic origin/master\n$ edit, commit, edit, commit, looks good\n$ git checkout master\n$ git pull # (1)\n$ git merge topic\n$ compile, test, etc\n$ git push origin master (2)\n$ git branch -d topic\n\n(1) this fast-forwards local master since local development is\n on topic.\n(2) as above, this fast-forwards\n git://central/repo.git/refs/heads/master from local master\n\nSo this way git://central/repo.git/refs/heads/master is never reset.\n\nBut, if you do have a valid reason for resetting, then what I said in\nmy previous message still applies.\n\nj.\n"},{"id":"108197","messageId":"20090317083452.GJ18475@coredump.intra.peff.net","threadId":"18329","inReplyTo":"fabb9a1e0903161343v458dec59oaae92794a367888c@mail.gmail.com","subject":"Re: fetch and pull","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-17T08:34:53Z","receivedAt":"2009-03-17T08:34:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 16, 2009 at 09:43:47PM +0100, Sverre Rabbelier wrote:\n\n> On Mon, Mar 16, 2009 at 21:39, John Dlugosz wrote:\n> > PT09IFJlOiA9PT0NCllvdSB2ZXJ5IGxpa2VseSBkbyBub3Qgd2FudCB0aGUg\n> \n> Forgot to turn off encryption?\n\nErny zra rapelcg va gurve urnqf.\n\n-Peff\n"},{"id":"108198","messageId":"fabb9a1e0903170136y7efb25adtdef706c189daaa7a@mail.gmail.com","threadId":"18329","inReplyTo":"20090317083452.GJ18475@coredump.intra.peff.net","subject":"Re: fetch and pull","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-03-17T08:36:17Z","receivedAt":"2009-03-17T08:36:17Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Mar 17, 2009 at 09:34, Jeff King wrote:\n> On Mon, Mar 16, 2009 at 09:43:47PM +0100, Sverre Rabbelier wrote:\n> Erny zra rapelcg va gurve urnqf.\n\nI always encrypt my messages with two-round ROT-13.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"108232","messageId":"450196A1AAAE4B42A00A8B27A59278E70A2AF22F@EXCHANGE.trad.tradestation.com","threadId":"18329","inReplyTo":"76718490903161709v6d8d09f6k17d2fe1a5e56fb03@mail.gmail.com","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-17T14:58:31Z","receivedAt":"2009-03-17T14:58:31Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> $ git clone git://central/repo.git\n> $ cd repo\n> $ git checkout -b topic origin/master\n> $ edit, commit, edit, commit, looks good\n> $ git checkout master\n> $ git pull\n\nYou checkout master before updating it?\n\n> $ git merge topic\n> $ compile, test, etc\n> $ git push origin master (2)\n> $ git branch -d topic\n\n> So this way git://central/repo.git/refs/heads/master is never reset.\n\n\n> But, if you do have a valid reason for resetting, then what I said in\n> my previous message still applies.\n\n\nThe developers may not non-ff the dev when they push it. But the repository maintainer may reset dev for some reason, and since topic branches are pushed, he can see that it either doesn't bother anyone that way or knows who to help out. But, it means that in general the pull _could_ be arbitrary and not a ff from his last pull.\n\nFor example, developer A checks in a finished topic, then B checks in a finished topic. But A doesn't use a spell checker even though he *really* should, and doesn't proof read even though he **really** should let a native English speaker look at it first. So the repository maintainer rewrites the tip of the dev branch. Next morning, everyone pulls, and both A and B are non-ff even though they have not branched anything from the old A or B.\n\n> Rarely, I'll base a topic on origin/pu. And origin/pu might get reset.\n> But even if it were, I wouldn't want to blindly reset my local branch\n> to match, thus losing my local changes. Instead I'd do this:\n\nThe local changes are all on a topic. Daily routine is to fetch and probably rebase topics each morning. Nobody checks out dev except to post a completed topic.\n\n--John\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"108249","messageId":"76718490903170921r36843c11y5aac537d53384298@mail.gmail.com","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A2AF22F@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-17T16:21:28Z","receivedAt":"2009-03-17T16:21:28Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Mar 17, 2009 at 10:58 AM, John Dlugosz\n wrote:\n>> $ git clone git://central/repo.git\n>> $ cd repo\n>> $ git checkout -b topic origin/master\n>> $ edit, commit, edit, commit, looks good\n>> $ git checkout master\n>> $ git pull\n>\n> You checkout master before updating it?\n\nYou cannot merge/rebase a branch unless it is checked out.\n\n> The developers may not non-ff the dev when they push it.  But the repository maintainer may reset dev for some reason, and since topic branches are pushed, he can see that it either doesn't bother anyone that way or knows who to help out.  But, it means that in general the pull _could_ be arbitrary and not a ff from his last pull.\n>\n> For example, developer A checks in a finished topic, then B checks in a finished topic.  But A doesn't use a spell checker even though he *really* should, and doesn't proof read even though he **really** should let a native English speaker look at it first.  So the repository maintainer rewrites the tip of the dev branch.  Next morning, everyone pulls, and both A and B are non-ff even though they have not branched anything from the old A or B.\n\nWe seem to not be understanding each other, and I apologize, but I\ncannot invest any more time in this thread. Perhaps others better\nunderstand what you are trying to do and can jump in.\n\nj.\n"},{"id":"108258","messageId":"450196A1AAAE4B42A00A8B27A59278E70A3FC0A5@EXCHANGE.trad.tradestation.com","threadId":"18329","inReplyTo":"76718490903170921r36843c11y5aac537d53384298@mail.gmail.com","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-17T16:44:31Z","receivedAt":"2009-03-17T16:44:31Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> On Tue, Mar 17, 2009 at 10:58 AM, John Dlugosz\n> wrote:\n> >> $ git clone git://central/repo.git\n> >> $ cd repo\n> >> $ git checkout -b topic origin/master\n> >> $ edit, commit, edit, commit, looks good\n> >> $ git checkout master\n> >> $ git pull\n> >\n> > You checkout master before updating it?\n> \n> You cannot merge/rebase a branch unless it is checked out.\n> \n\nSure you can.\n\tgit rebase upstream topic\n\nBut I think I see the point: the implicit merge done by pull uses the current HEAD and config branch..merge.\n\nMy concern is that you establish your working state based on the local 'master', only to immediately change it again when the pull updates master. But that's the way it's supposed to work?\n\nI think the documentation for git-pull might also be garbled from text being of different eras. \"Normally the branch merged is the HEAD of the remote\"? That will be basically random since the last thing the upstream repo user did will control what his HEAD is.\n\nBut, the intention here is\n 1) direct attention to the desired branch\n 2) do what is appropriate for the current branch\n\nThe key to avoiding massive confusion is making sure that (2) is set up properly. I never know what's going to happen with a pull, and I suppose that's because nothing was set up properly.\n\n--John (still confused)\n\n\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"108284","messageId":"20090318063103.6117@nanako3.lavabit.com","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A3FC0A5@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-03-17T21:31:03Z","receivedAt":"2009-03-17T21:31:03Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting John Dlugosz :\n\n> My concern is that you establish your working state based on the local 'master', only to immediately change it again when the pull updates master. But that's the way it's supposed to work?\n>\n> I think the documentation for git-pull might also be garbled from text being of different eras. \"Normally the branch merged is the HEAD of the remote\"? That will be basically random since the last thing the upstream repo user did will control what his HEAD is.\n\nThat's how it's supposed to work, and the documentation isn't from a different era, either. Majority of users clone from a central repository and keep pulling to update their clones, and in that kind of setting, HEAD will never change. A HEAD in a bare repository tells people which branch is the primary branch of the project.\n\nI think you are confused because you are thinking that it's typical to pull from a live repository that has a working tree somebody else uses to grow his history, and you are correct that you can't predict which branch HEAD points at at any given moment. But that isn't how a typical workflow uses pull and push between repositories.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"108297","messageId":"20090318003752.GA25454@coredump.intra.peff.net","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A3FC0A5@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-18T00:37:53Z","receivedAt":"2009-03-18T00:37:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 17, 2009 at 12:44:31PM -0400, John Dlugosz wrote:\n\n> > > You checkout master before updating it?\n> > \n> > You cannot merge/rebase a branch unless it is checked out.\n> > \n> Sure you can.\n> \tgit rebase upstream topic\n\nThis literally does a \"checkout\" behind the scenes, so it is still\nmanipulating your working tree. It is basically the equivalent of:\n\n git checkout topic && git rebase upstream\n\nThe actual rebasing happens on a detached HEAD, but you will find at the\nend of such a rebase that you are now on the branch \"topic\".\n\n-Peff\n"},{"id":"108355","messageId":"20090318085849.GA8118@atjola.homenet","threadId":"18329","inReplyTo":"20090318063103.6117@nanako3.lavabit.com","subject":"Re: fetch and pull","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-03-18T08:58:49Z","receivedAt":"2009-03-18T08:58:49Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.03.18 06:31:03 +0900, Nanako Shiraishi wrote:\n> Quoting John Dlugosz :\n> > I think the documentation for git-pull might also be garbled from\n> > text being of different eras. \"Normally the branch merged is the\n> > HEAD of the remote\"? That will be basically random since the last\n> > thing the upstream repo user did will control what his HEAD is.\n> \n> That's how it's supposed to work, and the documentation isn't from a\n> different era, either. Majority of users clone from a central\n> repository and keep pulling to update their clones, and in that kind\n> of setting, HEAD will never change. A HEAD in a bare repository tells\n> people which branch is the primary branch of the project.\n\nBut _if_ HEAD changes in the remote repo, that has normally no effect on\nthe behaviour of pull. Especially since the examples in the man page are\n\"git pull\" and \"git pull origin\".\n\nAFAICT the remote's HEAD affects the pull behaviour when:\n\n1) You do \"git pull git://host/repo.git\" or similar, i.e. you don't use\na remote. Because then, no refspec is given to fetch, and it defaults to\nfetching HEAD.\n\n2) You do \"git pull origin\" and there's no remote.origin.fetch set, same\nas above then.\n\n3) You do \"git pull\" and either is branch..remote set to an url\n(same as 1) then) or to a remote that has no default fetch refspec set\n(same as 2) then).\n\n\n1) probably isn't that common for most users, and even if, it's not\none of the commands given as examples to which the paragraph applies.\n\n2) I don't think that's a common setup, and it's not a default setup, so\nthat hardly qualifies for \"normally\".\n\n3) I've actually seen cases of the first form of this setup (remote set\nto an url), but usually that was paired with a confused user.\n\n\nSo while it's true that the remote's HEAD might be what you merge, it's\nnot quite what happens \"normally\". Of course it's true that the most\ncommon setup is probably that HEAD references master and that\nbranch..merge is also set to refs/heads/master, but while the\noutcome is basically the same, I'd rather say that that is a coincidence\nrather than what the text means to the reader.\n\n\nI'm unsure about how to improve that section though. Basically, the last\nparagraph (\"When no refspec was given ...\") above the EXAMPLES section\nneeds to be repeated, but that feels wrong. Anyone got a better idea?\n\nWell, at least I finally realised that pull _might_ default to the\nremote's HEAD, and for that part, I'll send a patch.\n\nBjörn\n"},{"id":"108358","messageId":"7v1vsvi339.fsf@gitster.siamese.dyndns.org","threadId":"18329","inReplyTo":"20090318085849.GA8118@atjola.homenet","subject":"Re: fetch and pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-18T09:37:30Z","receivedAt":"2009-03-18T09:37:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> 1) You do \"git pull git://host/repo.git\" or similar, i.e. you don't use\n> a remote. Because then, no refspec is given to fetch, and it defaults to\n> fetching HEAD.\n> ...\n> 1) probably isn't that common for most users, and even if, it's not\n> one of the commands given as examples to which the paragraph applies.\n\nI think \"a maintainer responds to a pull request\" is the only case that\nhappens often in practice for a fetch+merge of HEAD from a remote\nrepository.\n\nEven in that case, we strongly encourage people to say not just \"which\nrepository location\" but also \"which branch\", i.e.\n\n\tLinus, please pull from:\n\n\t\tgit://git.or.cz/alt-git.git for-linus\n\n\tto obtain the following commits.\n\nWhen Linus cuts and pastes that to his shell, the command will become:\n\n\t$ git pull git://git.or.cz/alt-git.git for-linus\n\nand HEAD is not involved in such a use case.\n"},{"id":"108375","messageId":"450196A1AAAE4B42A00A8B27A59278E70A3FC468@EXCHANGE.trad.tradestation.com","threadId":"18329","inReplyTo":"20090318085849.GA8118@atjola.homenet","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-18T15:18:41Z","receivedAt":"2009-03-18T15:18:41Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> 2) I don't think that's a common setup, and it's not a default setup,\n> so\n> that hardly qualifies for \"normally\".\n\nHow many users of git on a team have it set up by someone who already knows what he's doing? I think bad or broken setups might be more common. For example, I didn't have any \"fetch\" setting under remote until I started reading this list and digging in more. And the upstream repository is not bare. \n\n\n\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"108376","messageId":"20090318153120.GC8118@atjola.homenet","threadId":"18329","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A3FC468@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-03-18T15:31:20Z","receivedAt":"2009-03-18T15:31:20Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.03.18 11:18:41 -0400, John Dlugosz wrote:\n> > 2) I don't think that's a common setup, and it's not a default\n> > setup, so that hardly qualifies for \"normally\".\n> \n> How many users of git on a team have it set up by someone who already\n> knows what he's doing? I think bad or broken setups might be more\n> common. For example, I didn't have any \"fetch\" setting under remote\n> until I started reading this list and digging in more.\n\nHm? Both clone and \"remote add\" setup the fetch line by default. So you\nmanually adjusted the config to add the remote as just an url alias? I'm\nnot convinced that such manual config changes are \"normal\" either. At\nleast you're most likely the first user from which I've heard that he\ndid that.\n\nBjörn\n"},{"id":"108384","messageId":"450196A1AAAE4B42A00A8B27A59278E70A3FC50D@EXCHANGE.trad.tradestation.com","threadId":"18329","inReplyTo":"20090318153120.GC8118@atjola.homenet","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-18T16:50:02Z","receivedAt":"2009-03-18T16:50:02Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> Hm? Both clone and \"remote add\" setup the fetch line by default. So you\n> manually adjusted the config to add the remote as just an url alias?\n> I'm\n> not convinced that such manual config changes are \"normal\" either. At\n> least you're most likely the first user from which I've heard that he\n> did that.\n\nNo, he manually added\n\t[remote \"pub\"]\n\turl = //...\n\nonly.\n\nI'm sure he wouldn't know \"clone\" if it bit him. I assume the entire repository and working tree was simply copied from his machine.\n\nThis is the same guy who insists on rebasing the dev branch. As soon as I learned to use \"git log\" I tried to convince him that he should merge, not rebase, but he won't listen. So I got control and did the merge (not rebase) and am trying to device a work-flow and matching cook book for the team.\n\nNobody thought to post to this mailing list either. So you have a selection bias in your sample. I speculate that there is a larger population of people who use git poorly, and that includes not participating in the community to learn better.\n\nJust like you can write Fortran in any language, git happily lets you treat it like SourceSafe, with a dash of \"just enough knowledge to be dangerous\" use of other features.\n\n--John\n(sorry about the footer)\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n If you received this in error, please contact the sender and delete the material from any computer.\n"}]}