Josh Steadmon [off-list ref] 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.
On 2021.09.10 17:52, Junio C Hamano wrote:
Josh Steadmon [off-list ref] writes:
quoted
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.
Thanks for the feedback. I've added "--track=direct" and
"--track=inherit" flags in V3, which I'll send out shortly. I am a bit
skeptical of the value of having "--track=direct" when just "--track"
still works, but I'll leave it up to the list to decide.