{"thread":{"id":"18684","subject":"More help with \"pull\" please","startedAt":"2009-04-01T19:28:51Z","lastAt":"2009-04-02T15:18:13Z","messageCount":8,"participants":["John Dlugosz","Tomas Carnecky","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"110159","messageId":"450196A1AAAE4B42A00A8B27A59278E70A7D4D9A@EXCHANGE.trad.tradestation.com","threadId":"18684","inReplyTo":null,"subject":"More help with \"pull\" please","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-01T19:28:51Z","receivedAt":"2009-04-01T19:28:51Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"I've actually given up on using \"git pull\" at all, preferring to fetch\nfirst, examine in gitk, and then decide whether to merge or whatever.\n\nThe problem I have is that it seems to always want to merge \"something\"\nwith the current checked-out branch.  It always throws the remote HEAD\ninto the mix, or if fetch lines are set up in the configuration file,\ntakes the first thing on there regardless of which branch I'm currently\nchecked out.  Maybe I'm wrong, but I just re-read the man page, forward\nand backwards, and am more bewildered than ever.\n\nAnyway, I want to help out a co-worker who has a more specialized\nsituation that may be right for a pull.  Also, I'll talk him through\ncloning the remote from the beginning, so the config files won't be all\nstrange or not setup from the previous users.\n\nThe only remaining issue is the remote in question:  it is not a bare\nrepository, and may be in use locally as well, at least for maintenance.\nSo I can't trust its HEAD to be anything reasonable at any given time.\n\nThis person wants to track a remote branch tip.  When that advances or\notherwise changes on the remote, update the working tree to match.  It\nwill always use the same branch, let's call it ReleaseCandidate for this\ndiscussion.\n\nMy question is:  What is the easiest way to create this local repository\nand operate it so that he can just keep it following that branch on the\nremote?\n\nThanks,\n--John\n(excuse the footer; it's not my idea)\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":"110161","messageId":"4659A860-4AF5-4E34-B38E-60C926E2BAE1@dbservice.com","threadId":"18684","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A7D4D9A@EXCHANGE.trad.tradestation.com","subject":"Re: More help with \"pull\" please","fromName":"Tomas Carnecky","fromEmail":"tom@dbservice.com","sentAt":"2009-04-01T20:15:37Z","receivedAt":"2009-04-01T20:15:37Z","isPatch":false,"sender":{"key":"tom@dbservice.com","avatar":"https://gravatar.com/avatar/900a300bdd1a8bbe086008ad78210bbee2ad2803b7d50a5cba04c1e9404bd6d2?d=mp&s=160"},"body":"\nOn Apr 1, 2009, at 9:28 PM, John Dlugosz wrote:\n\n> I've actually given up on using \"git pull\" at all, preferring to fetch\n> first, examine in gitk, and then decide whether to merge or whatever.\n>\n> The problem I have is that it seems to always want to merge  \n> \"something\"\n> with the current checked-out branch.  It always throws the remote HEAD\n> into the mix, or if fetch lines are set up in the configuration file,\n> takes the first thing on there regardless of which branch I'm  \n> currently\n> checked out.  Maybe I'm wrong, but I just re-read the man page,  \n> forward\n> and backwards, and am more bewildered than ever.\n\nWhen you create a branch, you can tell git which remote branch it  \ntracks, like this:\n\n$ git branch --track mynext origin/next\n\nSo whenever you are on brach 'mynext' and do a git-pull, it will fetch  \nand merge origin/next.\n\nYou can do the same with the git-checkout command:\n\n$ git checkout --track origin/next\n\nThis will create a local branch 'next' which tracks 'origin/next'\n\n> Anyway, I want to help out a co-worker who has a more specialized\n> situation that may be right for a pull.  Also, I'll talk him through\n> cloning the remote from the beginning, so the config files won't be  \n> all\n> strange or not setup from the previous users.\n>\n> The only remaining issue is the remote in question:  it is not a bare\n> repository, and may be in use locally as well, at least for  \n> maintenance.\n> So I can't trust its HEAD to be anything reasonable at any given time.\n>\n> This person wants to track a remote branch tip.  When that advances or\n> otherwise changes on the remote, update the working tree to match.  It\n> will always use the same branch, let's call it ReleaseCandidate for  \n> this\n> discussion.\n>\n> My question is:  What is the easiest way to create this local  \n> repository\n> and operate it so that he can just keep it following that branch on  \n> the\n> remote?\n\n$ git clone $url XXX\n$ cd XXX\n$ git checkout --trach origin/ReleaseCandidate\n...\n$ git pull # will automatically fetch and merge origin/ReleaseCandidate\n\ntom\n"},{"id":"110173","messageId":"450196A1AAAE4B42A00A8B27A59278E70A7D4E71@EXCHANGE.trad.tradestation.com","threadId":"18684","inReplyTo":"4659A860-4AF5-4E34-B38E-60C926E2BAE1@dbservice.com","subject":"RE: More help with \"pull\" please","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-01T22:53:10Z","receivedAt":"2009-04-01T22:53:10Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> When you create a branch, you can tell git which remote branch it\n> tracks, like this:\n> \n> $ git branch --track mynext origin/next\n> \n> So whenever you are on brach 'mynext' and do a git-pull, it will fetch\n> and merge origin/next.\n> \n> You can do the same with the git-checkout command:\n> \n> $ git checkout --track origin/next\n> \n> This will create a local branch 'next' which tracks 'origin/next'\n> \n\nOK, that works by adding something to the config file, right?  The docs\ndon't say, but does mention \"having Pull: <refspec> lines for a\n<repository>\".  Does tracking add Pull: lines, or is that another\nfeature?\n\n> \n> $ git clone $url XXX\n> $ cd XXX\n> $ git checkout --track origin/ReleaseCandidate\n> ...\n> $ git pull # will automatically fetch and merge\norigin/ReleaseCandidate\n\nAccording to the manpage on pull, \"While git-pull run without any\nexplicit <refspec> parameter takes default <refspec>s from Pull: lines,\nit merges only the first <refspec> found into the current branch, after\nfetching all the remote refs.\"\n\nAlso, \"When no refspec was given on the command line ... If\nbranch.<name>.merge configuration for the current branch <name> exists,\nthat is the name of the branch at the remote site that is merged.\"  So\nis that yet again different from having Pull: lines?  If so, I'm fine if\nno \"Pull:\" lines exist, or it would merge the first refspec found there.\n\nAlso, \"Normally the branch merged in is the HEAD of the remote\nrepository, but the choice is determined by the branch.<name>.remote and\nbranch.<name>.merge options; see git-config(1) for details.\"  That\nagrees with the previous.  If branch.<name>.merge configuration exists,\nI don't need to worry about the remote HEAD.\n\n\n> $ git checkout --track origin/ReleaseCandidate\n\nThat command does not work.  It compains that --track can only be used\nwith -b, etc.\n\nI think \n\tgit checkout -b origin/ReleaseCandidate\n\nis the correct shortcut?  \n\n\tgit checkout -b ReleaseCandidate origin/ReleaseCandidate\n\ndid work.  I know that --track is automatic if the second argument is\nremote.\n\n--John\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":"110175","messageId":"F364AB31-EC5B-4719-834E-58613BDBC433@dbservice.com","threadId":"18684","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A7D4E71@EXCHANGE.trad.tradestation.com","subject":"Re: More help with \"pull\" please","fromName":"Tomas Carnecky","fromEmail":"tom@dbservice.com","sentAt":"2009-04-01T23:14:45Z","receivedAt":"2009-04-01T23:14:45Z","isPatch":false,"sender":{"key":"tom@dbservice.com","avatar":"https://gravatar.com/avatar/900a300bdd1a8bbe086008ad78210bbee2ad2803b7d50a5cba04c1e9404bd6d2?d=mp&s=160"},"body":"\nOn Apr 2, 2009, at 12:53 AM, John Dlugosz wrote:\n\n>> When you create a branch, you can tell git which remote branch it\n>> tracks, like this:\n>>\n>> $ git branch --track mynext origin/next\n>>\n>> So whenever you are on brach 'mynext' and do a git-pull, it will  \n>> fetch\n>> and merge origin/next.\n>>\n>> You can do the same with the git-checkout command:\n>>\n>> $ git checkout --track origin/next\n>>\n>> This will create a local branch 'next' which tracks 'origin/next'\n>>\n>\n> OK, that works by adding something to the config file, right?  The  \n> docs\n> don't say, but does mention \"having Pull: <refspec> lines for a\n> <repository>\".  Does tracking add Pull: lines, or is that another\n> feature?\n\nI think Pull: lines are not used anymore in newer repositories.  \nTracking is done through the 'branch.<name>.remote' and  \n'branch.<name>.merge' config options (which are automatically set by  \ngit-branch/git-checkout when you use --track).\n\n>>\n>> $ git clone $url XXX\n>> $ cd XXX\n>> $ git checkout --track origin/ReleaseCandidate\n>> ...\n>> $ git pull # will automatically fetch and merge\n> origin/ReleaseCandidate\n>\n> According to the manpage on pull, \"While git-pull run without any\n> explicit <refspec> parameter takes default <refspec>s from Pull:  \n> lines,\n> it merges only the first <refspec> found into the current branch,  \n> after\n> fetching all the remote refs.\"\n>\n> Also, \"When no refspec was given on the command line ... If\n> branch.<name>.merge configuration for the current branch <name>  \n> exists,\n> that is the name of the branch at the remote site that is merged.\"  So\n> is that yet again different from having Pull: lines?  If so, I'm  \n> fine if\n> no \"Pull:\" lines exist, or it would merge the first refspec found  \n> there.\n>\n> Also, \"Normally the branch merged in is the HEAD of the remote\n> repository, but the choice is determined by the branch.<name>.remote  \n> and\n> branch.<name>.merge options; see git-config(1) for details.\"  That\n> agrees with the previous.  If branch.<name>.merge configuration  \n> exists,\n> I don't need to worry about the remote HEAD.\n\nI'd say forget about Pull: because you won't see any of that in newer  \nrepositories. Instead, just use --track when checking out a branch you  \nintend to follow. And, more as an implementation detail than anything  \nelse, remember that the tracking is done through the above mentioned  \nconfig options (which you can set/change using git-config or directly  \nby editing the .git/config file).\n\n>\n>> $ git checkout --track origin/ReleaseCandidate\n>\n> That command does not work.  It compains that --track can only be used\n> with -b, etc.\n>\n> I think\n> \tgit checkout -b origin/ReleaseCandidate\n>\n> is the correct shortcut?\n>\n> \tgit checkout -b ReleaseCandidate origin/ReleaseCandidate\n>\n> did work.  I know that --track is automatic if the second argument is\n> remote.\n\nMaybe it's because I'm using a fairly recent version  \n(1.6.2.1.307.g91408).\n\ntom\n"},{"id":"110176","messageId":"450196A1AAAE4B42A00A8B27A59278E70A7D4E7B@EXCHANGE.trad.tradestation.com","threadId":"18684","inReplyTo":"F364AB31-EC5B-4719-834E-58613BDBC433@dbservice.com","subject":"RE: More help with \"pull\" please","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-01T23:26:12Z","receivedAt":"2009-04-01T23:26:12Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> I think Pull: lines are not used anymore in newer repositories.\n...\n> I'd say forget about Pull: because you won't see any of that in newer\n> repositories. Instead, just use --track when checking out a branch you\n> intend to follow. And, more as an implementation detail than anything\n> else, remember that the tracking is done through the above mentioned\n> config options (which you can set/change using git-config or directly\n> by editing the .git/config file).\n\nOK, the documentation is clear if I ignore that.\nI expect it to be \"well behaved\" if I'm on a tracking branch and give it\nno arguments, or if the single refspec argument is the correct remote\nfor the branch I'm on.  Otherwise (not a tracking branch) the docs just\nsay \"It's complicated, backward compatibility\" and presumably involves\nthose non-existent Pull: lines and the state of the remote's HEAD.\n\n\n\n> Maybe it's because I'm using a fairly recent version\n> (1.6.2.1.307.g91408).\n\nI'm running git version (1.6.2.msysgit.0.186.gf7512), and I assume my\ncoworker's was a bit older.\n\n--John\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":"110181","messageId":"7viqlnokrv.fsf@gitster.siamese.dyndns.org","threadId":"18684","inReplyTo":"F364AB31-EC5B-4719-834E-58613BDBC433@dbservice.com","subject":"Re: More help with \"pull\" please","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-02T02:24:20Z","receivedAt":"2009-04-02T02:24:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tomas Carnecky <tom@dbservice.com> writes:\n\n>> OK, that works by adding something to the config file, right?  The\n>> docs\n>> don't say, but does mention \"having Pull: <refspec> lines for a\n>> <repository>\".  Does tracking add Pull: lines, or is that another\n>> feature?\n>\n> I think Pull: lines are not used anymore in newer\n> repositories.\n\nIf your repository is using .git/remotes/origin to name the \"origin\"\nremote, they are still honored.  But you are correct to point out that\nbranch.<name>.remote and with the remote.<name>.* variables in .git/config\nare used to control these more recent features.  So in that sense the\ndocumentation is still correct.\n"},{"id":"110221","messageId":"450196A1AAAE4B42A00A8B27A59278E70A7D4FF7@EXCHANGE.trad.tradestation.com","threadId":"18684","inReplyTo":"7viqlnokrv.fsf@gitster.siamese.dyndns.org","subject":"RE: More help with \"pull\" please","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-02T14:45:12Z","receivedAt":"2009-04-02T14:45:12Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"> If your repository is using .git/remotes/origin to name the \"origin\"\n\nI don't have a directory under .git called remotes.  A new repository\nmade using clone describes origin in the config file.  Is that an old\nway of doing things?\n\n> remote, they are still honored.  But you are correct to point out that\n> branch.<name>.remote and with the remote.<name>.* variables in\n> .git/config\n> are used to control these more recent features.  So in that sense the\n> documentation is still correct.\n\nA related question:  is the name \"origin\" hard-coded as the default, or\ndoes each repository remember specifically which is the upstream\nrepository regardless of what you named it?  From what I see in the\nconfig file, it would have to be per-branch.  I suppose in other cases\nit's implicit in where the label was found under remotes.\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.\n  If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"110222","messageId":"1E580393-D051-4259-B4DE-CFFC9082C87A@dbservice.com","threadId":"18684","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A7D4FF7@EXCHANGE.trad.tradestation.com","subject":"Re: More help with \"pull\" please","fromName":"Tomas Carnecky","fromEmail":"tom@dbservice.com","sentAt":"2009-04-02T15:18:13Z","receivedAt":"2009-04-02T15:18:13Z","isPatch":false,"sender":{"key":"tom@dbservice.com","avatar":"https://gravatar.com/avatar/900a300bdd1a8bbe086008ad78210bbee2ad2803b7d50a5cba04c1e9404bd6d2?d=mp&s=160"},"body":"\nOn Apr 2, 2009, at 4:45 PM, John Dlugosz wrote:\n\n>> If your repository is using .git/remotes/origin to name the \"origin\"\n>\n> I don't have a directory under .git called remotes.  A new repository\n> made using clone describes origin in the config file.  Is that an old\n> way of doing things?\n\nYep. Earlier git versions used one config file per remote. Newer git  \nversions use the .git/config file.\n\n>> remote, they are still honored.  But you are correct to point out  \n>> that\n>> branch.<name>.remote and with the remote.<name>.* variables in\n>> .git/config\n>> are used to control these more recent features.  So in that sense the\n>> documentation is still correct.\n>\n> A related question:  is the name \"origin\" hard-coded as the default,  \n> or\n> does each repository remember specifically which is the upstream\n> repository regardless of what you named it?  From what I see in the\n> config file, it would have to be per-branch.  I suppose in other cases\n> it's implicit in where the label was found under remotes.\n\n'origin' is the default name for the remote you cloned from. But there  \nis nothing special to it other than being a default name used  \nthroughout git. You can manually add remotes under a different name if  \nyou like.\n\n$ git clone $url ./xyz\n\nis roughly the same as:\n\n$ mkdir ./xyz && cd ./xyz\n$ git init\n$ git remote add origin $url\n$ git fetch origin\n$ git checkout -b master origin/master\n\ntom\n"}]}