Josh Steadmon <steadmon@xxxxxxxxxx> writes: > It can be helpful when creating a new branch to use the existing > tracking configuration from the branch point. However, there is > currently not a method to automatically do so. > > Teach branch.autoSetupMerge a new "inherit" option. When this is set, > creating a new branch will cause the tracking configuration to default > to the configuration of the branch point, if set. So, when a new branch N is forked from an existing branch A that builds on branch B (which could be a local branch under refs/heads/ or a remote-tracking branch under refs/remotes/), a plain-vanilla auto-setup-merge makes N build on A but with 'inherit', N is marked to build on B instead? I do not think it is wise to hide this useful feature behind a configuration variable. Rather, this should be made available first to users who do not even set the configuration and then as a convenience measure, made usable via the configuration mechanism as well. The current "git branch --track N A" makes N build on A, so perhaps "git branch --track=inherit N A" should make N build on whatever A builds on. We may need to give a synonym --track=direct to the traditional "build on the original branch that was used to specfy the fork point" while doing so. And then on top of that, we can add configuration variable handling. Depending on the value of branch.autoSetupMerge, "git branch -b" and "git checkout -b" would pretend as if "--track" or "--track=inherit" were given, or something along that line. The end result may be the same for those who only use the configuration variables, but it would give us some flexibility to countermand the configuration from the command line. Those who set branch.autoSetupMerge to 'inherit' cannot say "git checkout -b N --track=direct A" to express "With this single invocation alone I am making N build on A, even though I know I usually make N build on whatever A builds on" if you give only the configuration variable. Thanks.
