{"thread":{"id":"18179","subject":"fetch and pull","startedAt":"2009-03-06T19:04:25Z","lastAt":"2009-03-09T15:27:53Z","messageCount":10,"participants":["John Dlugosz","Junio C Hamano","Jakub Narebski","Bryan Donlan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"107235","messageId":"450196A1AAAE4B42A00A8B27A59278E70A115E0D@EXCHANGE.trad.tradestation.com","threadId":"18179","inReplyTo":null,"subject":"fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-06T19:04:25Z","receivedAt":"2009-03-06T19:04:25Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"I've gotten the hang of git well enough to pretty much bang on it until\nI achieve what I wanted to happen, though maybe trying a few things and\nrecovering from mistakes or taking the long way around.\n\nNow I'm putting together a cookbook for our team, to allow use of topic\nbranches rather than treating it simply as a faster SourceSafe.\n\nI want to advocate running\n\n\tgit fetch\n\nas being a safe thing to do at any time, just to refresh your view of\nthe origin and not mess up any of your local labels. That is, you can\nsee the difference between the local dev and the origin/dev.\n\nSo, after inspecting the changes, how do you fast-forward your local dev\nto sync up with origin/dev?\n\nI'm worried that\n\n\tgit pull origin dev\n\nwill try to merge into the current head. The documentation indicates\n\"The remote ref that matches is fetched, and if is not empty\nstring, the local ref that matches it is fast forwarded using .\"\nwhich is what I want, but it does NOT say that the normal behavior of\nmerging origin/dev into the =current= HEAD, if it happens to not be the\nlocal dev.\n\nSo, does it indeed suppress that behavior if you give it an explicit\ndestination? Or will I have to checkout dev first before doing the\npull, to prevent strange things from happening? Hmm, or perhaps I\nshould be using merge, not pull? After all, pull is really just a\nwrapper around fetch and then merge, right? So is it OK to call merge\nwhen I really want to fast-forward, and is there an option to give an\nerror if it isn't ff?\n\n--John\n(sorry about 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":"107237","messageId":"7vljrisb7u.fsf@gitster.siamese.dyndns.org","threadId":"18179","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A115E0D@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-06T19:27:49Z","receivedAt":"2009-03-06T19:27:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"John Dlugosz\" writes:\n\n> I've gotten the hang of git well enough to pretty much bang on it until\n> I achieve what I wanted to happen, though maybe trying a few things and\n> recovering from mistakes or taking the long way around.\n>\n> Now I'm putting together a cookbook for our team, to allow use of topic\n> branches rather than treating it simply as a faster SourceSafe.\n>\n> I want to advocate running\n>\n> \tgit fetch\n>\n> as being a safe thing to do at any time, just to refresh your view of\n> the origin and not mess up any of your local labels. That is, you can\n> see the difference between the local dev and the origin/dev.\n>\n> So, after inspecting the changes, how do you fast-forward your local dev\n> to sync up with origin/dev?\n\n$ git push . origin/dev dev\n"},{"id":"107239","messageId":"m3iqmmidlf.fsf@localhost.localdomain","threadId":"18179","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A115E0D@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-03-06T20:44:49Z","receivedAt":"2009-03-06T20:44:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"John Dlugosz\" writes:\n\n> So, after inspecting the changes, how do you fast-forward your local dev\n> to sync up with origin/dev?\n> \n> I'm worried that\n> \n> \tgit pull origin dev\n> \n> will try to merge into the current head. The documentation indicates\n> \"The remote ref that matches is fetched, and if is not empty\n> string, the local ref that matches it is fast forwarded using .\"\n> which is what I want, but it does NOT say that the normal behavior of\n> merging origin/dev into the =current= HEAD, if it happens to not be the\n> local dev.\n> \n> So, does it indeed suppress that behavior if you give it an explicit\n> destination? Or will I have to checkout dev first before doing the\n> pull, to prevent strange things from happening? Hmm, or perhaps I\n> should be using merge, not pull? After all, pull is really just a\n> wrapper around fetch and then merge, right? So is it OK to call merge\n> when I really want to fast-forward, and is there an option to give an\n> error if it isn't ff?\n\nThere was patch series adding support --ff=only, but I think it didn't\nmade into git... Hmmm...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"107240","messageId":"7vd4cus7ez.fsf@gitster.siamese.dyndns.org","threadId":"18179","inReplyTo":"m3iqmmidlf.fsf@localhost.localdomain","subject":"Re: fetch and pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-06T20:49:56Z","receivedAt":"2009-03-06T20:49:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> \"John Dlugosz\" writes:\n>\n>> So, after inspecting the changes, how do you fast-forward your local dev\n>> to sync up with origin/dev?\n>> \n>> I'm worried that\n>> \n>> \tgit pull origin dev\n>> \n>> will try to merge into the current head. The documentation indicates\n>> \"The remote ref that matches is fetched, and if is not empty\n>> string, the local ref that matches it is fast forwarded using .\"\n>> which is what I want, but it does NOT say that the normal behavior of\n>> merging origin/dev into the =current= HEAD, if it happens to not be the\n>> local dev.\n>> \n>> So, does it indeed suppress that behavior if you give it an explicit\n>> destination? Or will I have to checkout dev first before doing the\n>> pull, to prevent strange things from happening? Hmm, or perhaps I\n>> should be using merge, not pull? After all, pull is really just a\n>> wrapper around fetch and then merge, right? So is it OK to call merge\n>> when I really want to fast-forward, and is there an option to give an\n>> error if it isn't ff?\n>\n> There was patch series adding support --ff=only, but I think it didn't\n> made into git... Hmmm...\n\nI do not think it has much to do with the main point of what John wants to\ndo which is to muck with local branch without checking it out, which is\nonly possible when it happens to fast forward to the new tip of the\ncorresponding branch obtained from the the remote.\n"},{"id":"107242","messageId":"450196A1AAAE4B42A00A8B27A59278E70A115F5D@EXCHANGE.trad.tradestation.com","threadId":"18179","inReplyTo":"7vd4cus7ez.fsf@gitster.siamese.dyndns.org","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-06T22:11:27Z","receivedAt":"2009-03-06T22:11:27Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"===Re:===\n> There was patch series adding support --ff=only, but I think it didn't\n> made into git... Hmmm...\n\nI do not think it has much to do with the main point of what John wants\nto\ndo which is to muck with local branch without checking it out, which is\nonly possible when it happens to fast forward to the new tip of the\ncorresponding branch obtained from the the remote.\n===end===\n\nIt occurs to me that maybe my concept is off, if it is being so\ndifficult.\n\nHere is what I'm \"cooking\":\n\n======excerpt======\n\nTo keep apprised of other people's work, including updates to the main\ndev branch, start the day with:\n\n\tgit fetch\n\nThis will update your \"remote tracking branches\", letting you see what\neveryone else is working on, and letting you see the central\nrepository's dev (as remotes/origin/dev) compared to your own local dev,\nso you can see what has been added.\n\nThis does not change your local dev, or any other branches you are\nusing. As for your own topic branches, you are the only one who changes\nthem. This is a perfectly safe command and can be performed any time to\nupdate your view of what's happening throughout the team.\nYou will, in particular, see your local dev where you last left it, and\nthe current remotes/origin/dev pointing ahead of it. E.g.\n\n\tA <== dev\n\t \\\n\t B--C--D <== remotes/origin/dev\n\nIn this example, you see plain \"dev\" still pointing to A, and\n\"remotes/origin/dev\" pointing to D. So, you can tell that B, C, D were\nadded. Review the nodes B, C, and D, by reading the comments and seeing\nwhich files were affected, and look deeper if it seems to affect what\nyou are doing. Finally, issue the command\n\n\t??? \n\nAnd this will update your local dev to match the origin.\n\n======\n\nBasically, instead of mysterious \"can't push\" messages, the idea is that\npeople can feel good about 'fetch' as refreshing their view of the\ncentral repo, so gitk can show them how the central dev (and other\nbranches) differs from their own. \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":"107246","messageId":"7v7i32s35t.fsf@gitster.siamese.dyndns.org","threadId":"18179","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A115F5D@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-06T22:21:50Z","receivedAt":"2009-03-06T22:21:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"John Dlugosz\" writes:\n\n> Here is what I'm \"cooking\":\n>\n> ======excerpt======\n>\n> To keep apprised of other people's work, including updates to the main\n> dev branch, start the day with:\n>\n> \tgit fetch\n>\n> This will update your \"remote tracking branches\", letting you see what\n> everyone else is working on, and letting you see the central\n> repository's dev (as remotes/origin/dev) compared to your own local dev,\n> so you can see what has been added.\n>\n> This does not change your local dev, or any other branches you are\n> using. As for your own topic branches, you are the only one who changes\n> them. This is a perfectly safe command and can be performed any time to\n> update your view of what's happening throughout the team.\n> You will, in particular, see your local dev where you last left it, and\n> the current remotes/origin/dev pointing ahead of it. E.g.\n>\n> \tA <== dev\n> \t \\\n> \t B--C--D <== remotes/origin/dev\n>\n> In this example, you see plain \"dev\" still pointing to A, and\n> \"remotes/origin/dev\" pointing to D. So, you can tell that B, C, D were\n> added. Review the nodes B, C, and D, by reading the comments and seeing\n> which files were affected, and look deeper if it seems to affect what\n> you are doing. Finally, issue the command\n>\n> \t??? \n>\n> And this will update your local dev to match the origin.\n>\n> ======\n\nI already answered that question in a separate message (that is\ndifferent from what you are replying to), didn't I?\n"},{"id":"107278","messageId":"3e8340490903070000t2780764cocfbf28d538037df5@mail.gmail.com","threadId":"18179","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70A115F5D@EXCHANGE.trad.tradestation.com","subject":"Re: fetch and pull","fromName":"Bryan Donlan","fromEmail":"bdonlan@gmail.com","sentAt":"2009-03-07T08:00:56Z","receivedAt":"2009-03-07T08:00:56Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Fri, Mar 6, 2009 at 5:11 PM, John Dlugosz wrote:\n> ===Re:===\n>> There was patch series adding support --ff=only, but I think it didn't\n>> made into git...  Hmmm...\n>\n> I do not think it has much to do with the main point of what John wants\n> to\n> do which is to muck with local branch without checking it out, which is\n> only possible when it happens to fast forward to the new tip of the\n> corresponding branch obtained from the the remote.\n> ===end===\n>\n> It occurs to me that maybe my concept is off, if it is being so\n> difficult.\n>\n> Here is what I'm \"cooking\":\n>\n> ======excerpt======\n>\n> To keep apprised of other people's work, including updates to the main\n> dev branch, start the day with:\n>\n>        git fetch\n>\n> This will update your \"remote tracking branches\", letting you see what\n> everyone else is working on, and letting you see the central\n> repository's dev (as remotes/origin/dev) compared to your own local dev,\n> so you can see what has been added.\n>\n> This does not change your local dev, or any other branches you are\n> using.  As for your own topic branches, you are the only one who changes\n> them.  This is a perfectly safe command and can be performed any time to\n> update your view of what's happening throughout the team.\n> You will, in particular, see your local dev where you last left it, and\n> the current remotes/origin/dev pointing ahead of it.  E.g.\n>\n>        A <== dev\n>         \\\n>          B--C--D <== remotes/origin/dev\n>\n> In this example, you see plain \"dev\" still pointing to A, and\n> \"remotes/origin/dev\" pointing to D.  So, you can tell that B, C, D were\n> added.  Review the nodes B, C, and D, by reading the comments and seeing\n> which files were affected, and look deeper if it seems to affect what\n> you are doing.  Finally, issue the command\n>\n>        ???\n>\n> And this will update your local dev to match the origin.\n>\n> ======\n>\n> Basically, instead of mysterious \"can't push\" messages, the idea is that\n> people can feel good about 'fetch' as refreshing their view of the\n> central repo, so gitk can show them how the central dev (and other\n> branches) differs from their own.\n\nIf the local \"dev\" is a topic branch, you'd want to either merge or\nrebase with the origin's dev branch. Rebasing is probably best if\nyou've not published the branch yet (unless you'd prefer proper merge\nhistory on it).\n\nIf the local \"dev\" is meant to just track the remote, you really ought\nto avoid doing anything very involved in it (unless you're planning on\nmerging something into it and pushing the result, that is!). If\nthere's no local changes, then you can just pull with impunity, and\nlet it fast-forward - or use git merge or git rebase if you've already\nfetched and don't want to spend the few seconds it takes to ask the\nserver if there's anything new :)\n\nFinally, if you really, truly, definitely want to blow away the\ncurrent branch and replace it with another one, you can use git reset\n--hard. This will throw away (irretrievably) local uncommitted\nchanges, and force the current branch to point to the specified one.\n\nRemember, you can undo most things using the reflog if you mess up,\nincluding unwanted merges, git reset --hard (committed changes only)\netc.\n"},{"id":"107336","messageId":"7vfxhpnl7g.fsf@gitster.siamese.dyndns.org","threadId":"18179","inReplyTo":"3e8340490903070000t2780764cocfbf28d538037df5@mail.gmail.com","subject":"Re: fetch and pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-07T20:15:31Z","receivedAt":"2009-03-07T20:15:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bryan Donlan writes:\n\n> If the local \"dev\" is meant to just track the remote, you really ought\n> to avoid doing anything very involved in it (unless you're planning on\n> merging something into it and pushing the result, that is!). If\n> there's no local changes, then you can just pull with impunity, and\n> let it fast-forward - or use git merge or git rebase if you've already\n> fetched and don't want to spend the few seconds it takes to ask the\n> server if there's anything new :)\n\nWith git that is not ancient (i.e. v1.5.0 or newer), there is no reason to\nhave local \"dev\" that purely track the remote anymore. If you only want\nto go-look-and-see, you can check out the remote tracking branch directly\non a detached HEAD with \"git checkout origin/dev\".\n\nWhich means that the only cases we need to make it convenient for users\nare to handle these local branches that \"track\" remote ones when you do\nhave local changes, or when you plan to have some.\n\nIf you do have local changes on \"dev\" that is marked to track the remove\n\"dev\", and if you are on a branch different from \"dev\", then we should not\ndo anything after \"git feftch\" updates the remote tracking \"dev\". It\nwon't fast forward anyway, and we do not need to talk about this case in\nthis thread.\n\nThat leaves only one case. Your \"dev\" forked from the remote \"dev\"\nsometime in the past, is marked to \"track\" the latter, but you haven't\ndone anything on the branch. Should we have a convenient way to\nfast-forward it after a \"git fetch\" that updates the remote \"dev\"?\n\nI'd actually say we should give users a convenient way to remove the local\nbranches that are marked to track remote tracking branches but do not have\nanything interesting on their own (iow when they can fast-forward to their\ncorresponding remote tracking branches), if the true motive behind this\nthread is \"'git push' will notice 'dev' that is left behind and gives\nclutter\".\n\nYes, you may earlier thought about building on top of the remote branch,\nbut you haven't done anything other than creating a branch, you left it\nwithout doing anything interesting and kept it behind.\n\nIf you later decide to revisit whatever you wanted to work on by forking\nfrom that branch, you can \"git checkout -t -b dev origin/dev\" at that time\nto recreate the branch just as easily as you would do \"git checkout dev\",\nand between the time you notice that you have a stale \"dev\" that does not\nhave anything interesting and the time you decide to really work on the\ntopic again, you may be better off not cluttering \"git branch\" output with\nsuch useless local branches.\n\nSo how about \"git branch --prune --remote=\" that iterates over\nlocal branches, and if\n\n (1) it is not the current branch; and\n (2) it is marked to track some branch taken from the ; and\n (3) it does not have any commits on its own;\n\nthen remove that branch? \"git remote --prune-local-forks \" is\nalso fine; I do not care about which command implements the feature that\nmuch.\n\nThe only case I think would be useful to keep a local branch that does not\nyet have a commit on its own happens in this workflow:\n\n (1) You notice a bug sometime in the past (or at the tip) of the \"dev\"\n branch you see in the remote;\n\n (2) You bisect, find a faulty commit, and fork your \"dev\" from that\n commit, so that you can work on fixing that single bug, later to be\n merged back (because you anticipate the fix would be an involved\n series);\n\n (3) But you haven't had a chance to work on the fix yet.\n\nYour fork point in this workflow has a meaning: this is the broken commit\nI fix with my commits immediately after it. It should not be rebased nor\nfast-forwarded.\n\nBut in that case, you shouldn't mark \"dev\" as tracking the remote's \"dev\"\nto begin with, so the hypothetical \"branch --prune --remote=\"\nwould not touch such a \"fork to address old issues\", and we'd be safe.\n"},{"id":"107463","messageId":"450196A1AAAE4B42A00A8B27A59278E70A11614B@EXCHANGE.trad.tradestation.com","threadId":"18179","inReplyTo":"3e8340490903070000t2780764cocfbf28d538037df5@mail.gmail.com","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-09T15:08:11Z","receivedAt":"2009-03-09T15:08:11Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"=== Re: ===\nIf the local \"dev\" is meant to just track the remote, [that is the case]\nyou really ought to avoid doing anything very involved in it (unless\nyou're \nplanning on merging something into it and pushing the result, that is!).\nIf\nthere's no local changes, then you can just pull with impunity, and\nlet it fast-forward - or use git merge or git rebase if you've already\nfetched and don't want to spend the few seconds it takes to ask the\nserver if there's anything new :)\n=== end ===\n\nI thought about that. But wouldn't that require you to checkout dev\nfirst? It seems that pull wants to merge into the current branch,\nperiod. That makes it unsuitable for something that just refreshes the\nremote view of things, and is an accident waiting to happen if you run\nit while on your topic branch instead.\n\n=== Re: ===\nFinally, if you really, truly, definitely want to blow away the\ncurrent branch and replace it with another one, you can use git reset\n--hard. This will throw away (irretrievably) local uncommitted\nchanges, and force the current branch to point to the specified one.\n=== end ===\n\n\"reset\" does not change the current branch. It updates the contents of\nthe working directory and index to match the node specified, but does\nnot change what git considers to be the branch you are \"on\". I got a\nfew floating heads and later merge confusion before I finally understood\nthat. It appears that \"checkout\" is the only thing that changes the\n\"current branch\". In any case, reset does not reposition any refs at\nall.\n\n=== Re: ===\nRemember, you can undo most things using the reflog if you mess up,\nincluding unwanted merges, git reset --hard (committed changes only)\netc.\n=== end ===\n\nYes, indeed.\n\n--John\n(please 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":"107465","messageId":"450196A1AAAE4B42A00A8B27A59278E70A116178@EXCHANGE.trad.tradestation.com","threadId":"18179","inReplyTo":"7vfxhpnl7g.fsf@gitster.siamese.dyndns.org","subject":"RE: fetch and pull","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-03-09T15:27:53Z","receivedAt":"2009-03-09T15:27:53Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"Thanks for your thoughts. I'm still trying to figure out not just the\nbasic meaning of the tools but what can be done with them.\n\n=== Re: ===\nWith git that is not ancient (i.e. v1.5.0 or newer), there is no reason\nto\nhave local \"dev\" that purely track the remote anymore. If you only want\nto go-look-and-see, you can check out the remote tracking branch\ndirectly\non a detached HEAD with \"git checkout origin/dev\".\n=== end ===\n\nYes, I figured out that since gitk shows the remote, there is no reason\nto have local copies of any master (upstream) refs that I don't plan on\nmodifying. After setting it to track remotes, I deleted all my unneeded\ncopies.\n\n=== Re: ===\nWhich means that the only cases we need to make it convenient for users\nare to handle these local branches that \"track\" remote ones when you do\nhave local changes, or when you plan to have some.\n=== end ===\n\nI also realized recently that, with the use of topic branches, the user\ndoesn't need to see the \"old\" (local copy of) dev to understand what\nchanged since he last looked. The visible branch point with the topic\nwill serve as that marker.\n\nThe only time the local dev is used is when the developer is going to\nadd a commit for the completed topic. But, dealing with it (only) then\nwould be more steps when doing that. And the local dev would still be\nvisible and out-dated from day-to-day, and when keeping the topic\nup-to-date with dev changes he would need to use origin/dev not just dev\nin his commands to rebase or merge.\n\n=== Re: ===\nI'd actually say we should give users a convenient way to remove the\nlocal\nbranches that are marked to track remote tracking branches but do not\nhave\nanything interesting on their own (iow when they can fast-forward to\ntheir\ncorresponding remote tracking branches), if the true motive behind this\nthread is \"'git push' will notice 'dev' that is left behind and gives\nclutter\".\n=== end ===\n\nI found that using the GUI was easy enough, when \"converting\" my local\nto track remote branches. If you mean make a way to have a local\nversion of a tracking branch transiently, that is, only when it is\ninteresting, then I think I like that idea.\n\n=== Re: ===\nSo how about \"git branch --prune --remote=\" that iterates over\nlocal branches, and if\n\n (1) it is not the current branch; and\n (2) it is marked to track some branch taken from the ; and\n (3) it does not have any commits on its own;\n\nthen remove that branch? \"git remote --prune-local-forks \" is\nalso fine; I do not care about which command implements the feature that\nmuch.\n=== end ===\n\nSince fetch is the command that does the tracking of remotes, how about\nhaving an option to fetch that does this before proceeding with the\nfetch? That is what people really want if they think they want locals\nto auto-track the remotes.\n\n=== Re: ===\nBut in that case, you shouldn't mark \"dev\" as tracking the remote's\n\"dev\"\nto begin with, so the hypothetical \"branch --prune --remote=\"\nwould not touch such a \"fork to address old issues\", and we'd be safe.\n=== end ===\n\nDoes git now \"associate\" local branch names with the remotes, other than\nby simply having the same name?\n\n--John\n(please excuse the footer; it's not my choice)\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"}]}