branch: let inherit track a remote-tracking start point - #2450

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

>  `inherit`;; if the starting point has a tracking configuration, it is copied to the new
> -	branch
> +	branch. A remote-tracking starting point is tracked directly, as with `true`.

That is "A remote-tracking branch given as a starting point", not "A
remote-tracking starting point".  Don't abbreviate and drop "branch".

If a starting point is not a remote-tracking branch, shouldn't the
same thing happen, by the way?  IOW, shouldn't the updated text and
behaviour be more like

	`inherit`;; if the starting point has a tracking
	configuration, it is copied to the new branch.  Otherwise,
	the new branch is set to track the starting point itself.

I am not sure if it is the users of `inherit` want that forking a
new branch from something that they know is *not* tracking anything
suddenly starts to track the starting point (whether it is a
remote-tracking branch or something else).

Looking at the originating commit d3115660b4 (branch: add flags and
config to inherit tracking, 2021-12-20), it only talks about what
they want to do when the starting point does track something, and
forgets to say what they want when it does not track anything (the
author CC'ed in case he retains the memory of the motivation from 5
years ago), but if you ask me _now_, not doing anything, i.e., the
behaviour the old commit happened to have implemented without
explanation does sound like the right thing to do.

What we should do if this change of behaviour turns out to be
undesirable?

Perhaps `inherit` should gain a synonym `inherit-or-ignore` for
those who prefer the current behaviour, and we want two extra
behaviours, `inherit-or-fail` that complains and dies if the
specified starting point does not have anything for the new branch
to inherit, and `inherit-or-direct` that uses the fallback
definition, or something?

On Fri, Oct 16, 2026 at 6:55 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> >  `inherit`;; if the starting point has a tracking configuration, it is copied to the new
> > -     branch
> > +     branch. A remote-tracking starting point is tracked directly, as with `true`.
>
> That is "A remote-tracking branch given as a starting point", not "A
> remote-tracking starting point".  Don't abbreviate and drop "branch".

Thanks!

> I am not sure if it is the users of `inherit` want that forking a
> new branch from something that they know is *not* tracking anything
> suddenly starts to track the starting point (whether it is a
> remote-tracking branch or something else).

For me it's simple, only tracking when the starting point is a remote branch.

> Looking at the originating commit d3115660b4 (branch: add flags and
> config to inherit tracking, 2021-12-20), it only talks about what
> they want to do when the starting point does track something, and
> forgets to say what they want when it does not track anything (the
> author CC'ed in case he retains the memory of the motivation from 5
> years ago), but if you ask me _now_, not doing anything, i.e., the
> behaviour the old commit happened to have implemented without
> explanation does sound like the right thing to do.
>
> What we should do if this change of behaviour turns out to be
> undesirable?
>
> Perhaps `inherit` should gain a synonym `inherit-or-ignore` for
> those who prefer the current behaviour, and we want two extra
> behaviours, `inherit-or-fail` that complains and dies if the
> specified starting point does not have anything for the new branch
> to inherit, and `inherit-or-direct` that uses the fallback
> definition, or something?

Seems quite overkill for the relatively small problem this is solving.
But it would be interesting to hear the original author's POV.


Harald