Dave Olszewski <cxreg@xxxxxxxxx> writes: > A common question from users creating branches in an environment where > they intend to push the branch to a shared bare repository, and then > later pull commits from upstream into the branch that they initially > created, is how do they create the branch with this tracking info > already set up. We try reasonably hard not to force users to make a decision before it gets absolutely necessary [*1*]. This option seems to only help users who can decide upfront upon "git branch" time if the branch is worth sharing with others and if the name of the branch will be the final one, and people who forget to give this new option when they ran "git branch", or those who changed their mind as to what the newly created branch with this option should interact with, will still need to use "git config" to update the settings. Not very nice, not because it solves only a part of the problem, but because it force users to decide early and not change their mind. Instead perhaps we would want to add an option to retarget an existing branch any time the user wants, e.g. "git branch --reconfigure"? Once we have such an option, people who *can* decide upfront can use that feature when creating a new branch at the same time. Also "git pull --remember $there $this" might be a good way to tell the configuration mechanism from the UI to remember that "I always want to merge $this branch from $there while on the branch I am currently on", and its implementation may probably use "git branch --reconfigure" internally. Having said all that, I am not very interested in topics on the mechanism that updates or uses these variables, as I tend to avoid relying on them myself, and instead teach people to spell them out (which seems to foster better understanding of what goes on, with reduced user confusion). Hence, I wouldn't claim I have thought things through in this area, and the above is just me thinking aloud [*2*]. [Footnote] *1* There are ample examples, ranging from detached HEAD (you do not have to decide if the experiment you are going to do deserves a separate branch to store the result permanently) to the separation between commit and push (what you commit does not have to be perfect and you have a chance to tidy them up before publishing). *2* IOW don't take my "I am not interested" as "patches in this area have little chance of getting applied." -- 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