Re: [PATCH] branch: let inherit track a remote-tracking start point

[Phillip Wood <phillip.wood123@gmail.com>]

On 16/10/2026 17:55, Junio C Hamano 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".
> 
> 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).

For me it depends on what I'm forking from. If I create a branch on my 
desktop, push it to my server and then create a local branch from that 
on my laptop, I normally want the new branch to track something like 
origin/master rather than the starting point. However, if I create a new 
branch from origin/master then I do want to track the starting point. So 
it is not clear to me that the behavior proposed here is better than the 
current behavior, but equally I don't think it is any worse. Having some 
way of saying "set up tracking when the starting point matches one of 
these patterns" might be useful, but I find the tracking options to "git 
switch -c" so confusing I normally just run "git branch 
--set-upstream-to" afterwards to set the upstream I want.

Thanks

Phillip


> 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?