On 10/29/2026 11:22 AM, Alex Bennée wrote: > Pierrick Bouvier <[email protected]> writes: > >> On 10/29/2026 9:26 AM, Alex Bennée wrote: >>> Pierrick Bouvier <[email protected]> writes: >>> >>>> On 10/29/2026 8:13 AM, Alex Bennée wrote: >>>>> The current check for a referenced fix commit relies on the developer >>>>> keeping their master branch up to date which is not always grunted. If >>>>> you create your branches directly from origin/master this will keep >>>>> failing. >>>>> >>>>> Given that origin/master should always be up to date (module the >>>>> developer eschewing convention) lets use that in the test instead. >>>>> >>>>> checkpatch complains about the line lengths but this seems to be >>>>> standard for the perl script so I didn't try and fix it. >>>>> >>>> >>>> Or... you can use something else as origin, with origin/master not being >>>> updated, and master as a tracking branch to upstream/master, and in this >>>> case, this patch doesn't work. >>>> >>>> Using master instead of origin/master has the advantage to not hardcode >>>> what your remotes should be. >>> >>> origin is the default when you clone a repo. We could get really complex >>> and query the tracking remote for the current branch. But if your deeply >>> forked then that obviates the test. >>> >> >> I am aware that origin is the default remote. >> In my case, I always use "upstream" to reference the original project, >> and "origin" for my personal fork. As a result, origin/master does not >> always track upstream/master. > > So master in that case won't be correct either? >
It's correct because it's setup as a tracking branch of upstream/master, and not origin/master. See help for `git branch --set-upstream-to=` if you're not familiar with it. Thus why I'm suggesting to either leave master as it is (and correctly update your personal local branch), or find which remote branch is tracked for master (see git branch -vv) to not break existing workflows.
