On Wed Oct 28, 2026 at 10:26 AM EDT, Junio C Hamano wrote:
quoted
quoted
This part of the code becomes overly deeply indented, and more
importantly, the outer conditional around here has been reworked by
another topic and the code that learns follow_remote_head will have
to be reused elsewhere, which would lead to a nasty merge conflict.
I'd like to see this part refactored into a separate helper
function, by squashing something like this on top of this patch.
[...]
The 'ch/remote-defer-follow-remote-head-validation' branch at
https://github.com/gitster/git/ has a change on top that you can use
as a reference. If you are going to make this a two-patch series, it
may make sense to first extract the code commented with "See
remote.c's handling of ..." into a helper function, and then extend
it to cover the lazy behavior in the second patch. When viewed
that way, the helper function should not be named with a 'lazy_'
prefix as I mistakenly did. Being lazy is not its purpose. Its
point is to determine which setting of followRemoteHEAD is to be
used, and the helper function should be named after that concept.
I wonder if it makes sense to incorporate such a new helper function
into the existing 'get_follow_remote_head()', since it would be the only
place using it.