Matt & Junio
I think a better justification is needed for this. The intent behind
'warn-if-not-<branch>' makes much less sense in the context of the fetch
variable imo, and if it turns out to be problematic, reverting support
later will be tricky.
I don't have a particularly strong justification for this, and was
already on the fence about including this change or not.
I likely will revert this addition for fetch, and make it so that this
only works for remote.
quoted
Messages for an unrecognized or missing value no longer name the
fetch. prefix, as the helper now serves both the fetch-level and
the remote-level setting.
I agree with Junio that this should be addressed.
I also went back and forth on how valuable this is, since if it's a
typo it should be clear which variable is incorrect.
But being detailed doesn't hurt, and in the event of an empty or " "
mistake then it will be even easier to identify the configuration
error.
quoted
@@ -139,6 +139,9 @@ remove the value for the `fetch.bundleCreationToken` value before fetching.
`warn`;;
Display a warning if the remote advertises a different `HEAD` than what is
set locally. Behaves like "create" if the local symbolic-ref doesn't exist.
+`warn-if-not-<branch>`;;
+ Like "warn", but do not display the warning if the remote's `HEAD`
+ is `remotes/<name>/<branch>`.
`always`;;
Silently update `remotes/<name>/HEAD` whenever the remote advertises a new
value.
I like the style change from $branch to <branch>
If I am reverting the change to fetch and warn-if-not, I will need to
revert the .adoc changes too, but I can make this change back in the
remote.adoc if we believe this is an improvement.
quoted
+ follow_remote_head = get_follow_remote_head(transport->remote->follow_remote_head_raw, &no_warn_branch);
else if (config->follow_remote_head_seen)
- follow_remote_head = get_follow_remote_head(config->follow_remote_head_raw);
+ follow_remote_head = get_follow_remote_head(config->follow_remote_head_raw, &no_warn_branch);
A couple more overly-long lines
I will clean these up, and the ones Junio mentioned, thanks for
pointing these out.
quoted
else
follow_remote_head = BUILTIN_FOLLOW_REMOTE_HEAD_DFLT;
}
By the way, I had previously made a comment about moving the definition
of 'enum follow_remote_head_settings' over to the fetch file since that
is now the only place it is relevant. Do you think it's worth changing?
Given the change I am proposing in remote.c where the enum is no
longer used, I do see the value in changing the scope of the enum, I
will experiment with this and update this in v2.
-Colin Hinton