Thanks for your thoughts. I'm still trying to figure out not just the basic meaning of the tools but what can be done with them. === Re: === With git that is not ancient (i.e. v1.5.0 or newer), there is no reason to have local "dev" that purely track the remote anymore. If you only want to go-look-and-see, you can check out the remote tracking branch directly on a detached HEAD with "git checkout origin/dev". === end === Yes, I figured out that since gitk shows the remote, there is no reason to have local copies of any master (upstream) refs that I don't plan on modifying. After setting it to track remotes, I deleted all my unneeded copies. === Re: === Which means that the only cases we need to make it convenient for users are to handle these local branches that "track" remote ones when you do have local changes, or when you plan to have some. === end === I also realized recently that, with the use of topic branches, the user doesn't need to see the "old" (local copy of) dev to understand what changed since he last looked. The visible branch point with the topic will serve as that marker. The only time the local dev is used is when the developer is going to add a commit for the completed topic. But, dealing with it (only) then would be more steps when doing that. And the local dev would still be visible and out-dated from day-to-day, and when keeping the topic up-to-date with dev changes he would need to use origin/dev not just dev in his commands to rebase or merge. === Re: === I'd actually say we should give users a convenient way to remove the local branches that are marked to track remote tracking branches but do not have anything interesting on their own (iow when they can fast-forward to their corresponding remote tracking branches), if the true motive behind this thread is "'git push' will notice 'dev' that is left behind and gives clutter". === end === I found that using the GUI was easy enough, when "converting" my local to track remote branches. If you mean make a way to have a local version of a tracking branch transiently, that is, only when it is interesting, then I think I like that idea. === Re: === So how about "git branch --prune --remote=<upstream>" that iterates over local branches, and if (1) it is not the current branch; and (2) it is marked to track some branch taken from the <upstream>; and (3) it does not have any commits on its own; then remove that branch? "git remote --prune-local-forks <upstream>" is also fine; I do not care about which command implements the feature that much. === end === Since fetch is the command that does the tracking of remotes, how about having an option to fetch that does this before proceeding with the fetch? That is what people really want if they think they want locals to auto-track the remotes. === Re: === But in that case, you shouldn't mark "dev" as tracking the remote's "dev" to begin with, so the hypothetical "branch --prune --remote=<upstream>" would not touch such a "fork to address old issues", and we'd be safe. === end === Does git now "associate" local branch names with the remotes, other than by simply having the same name? --John (please excuse the footer; it's not my choice) TradeStation 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
