On Fri, Mar 11, 2016 at 10:21 AM, Paul Tan <pyokagan@xxxxxxxxx> wrote: > Stepping back a bit, the only reason why we introduced opt_autostash = > -1 as a possible value is because we need to detect if > --[no-]autostash is being used with git-merge. I consider that a > kludge, because if git-merge supports --autostash as well (possibly in > the future), then we will not need this -1 value. No, there is one more reason for which opt_autostash = -1 is required. When user calls "git pull --rebase" then config_autostash value will be used to perform --[no-]autostash task but if user calls "git pull --rebase --[no-]autostash" then config_autostash value should not be read at all as this option is supposed to override config_autostash value. So if opt_autostash defaults to 0 then how will the code understand if "--[no-]autostash" flag is passed or not? As per the current patch, the value opt_autostash = 0 or 1 tells us that the user has explicitly asked for --no-autostash or --autostash respectively, and -1 value tells us that user has not specified anything and thus we should read config_autostash value to perform --[no-]autostash. One way to do this was to read rebase.autoStash before parse_options(), but now as we have introduced a callback function git_pull_config(), reading this config variable before parse_option() will now require calling git_config(git_pull_config, NULL) before parse_option() and doing opt_autostash = config_autostash there only.This may lead to some problems (I'm not sure of that), as git_config() reads many other config variables too. Thanks, Mehul -- 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