On Wed, Jun 10, 2015 at 10:38 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Paul Tan <pyokagan@xxxxxxxxx> writes:
>>
>>> @@ -422,6 +423,14 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
>>>
>>> parse_repo_refspecs(argc, argv, &repo, &refspecs);
>>>
>>> + git_config(git_default_config, NULL);
>>> +
>>> + if (read_cache_unmerged())
>>> + die_resolve_conflict("Pull");
>>> +
>>> + if (file_exists(git_path("MERGE_HEAD")))
>>> + die_conclude_merge();
>>> +
>>> if (!opt_ff.len)
>>> config_get_ff(&opt_ff);
>>
>> Hmph.
>>
>> If you are going to do the git_config() call yourself, it might make
>> more sense to define git_pull_config() callback and parse the pull.ff
>> yourself, updating the use of the lazy git_config_get_value() API you
>> introduced in patch 10/19.
>>
>> The above "might" is stronger than my usual "might"; I am undecided
>> yet before reading the remainder of the series.
>
> Let me clarify the above with s/stronger/with much less certainty/;
Uh, I have no idea what a "strong might" or a "less certain might" is. :-/
Parsing all the config values with a git_config() callback function is
certainly possible, but I was under the impression that we are moving
towards migrating use of all the git_config() callback loops to the
git_config_get_X() API.
In this case though, we have to use git_config() to initialize the
advice.resolveConflict config setting, but I don't see why it must be
in conflict with the above goal.
Thanks,
Paul
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html