| Message ID | 20230228140236.4175835-3-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Example of pull.mode | expand |
diff --git a/builtin/pull.c b/builtin/pull.c index 0531328e2f..3c9e7f0861 100644 --- a/builtin/pull.c +++ b/builtin/pull.c @@ -68,8 +68,14 @@ static int parse_opt_rebase(const struct option *opt, const char *arg, int unset if (arg) *value = parse_config_rebase("--rebase", arg, 0); - else - *value = unset ? REBASE_FALSE : REBASE_TRUE; + else { + if (!unset) { + /* --rebase shouldn't override pull.rebase=merges (and others) */ + if (*value < REBASE_TRUE) + *value = REBASE_TRUE; + } else + *value = REBASE_FALSE; + } if (*value > 0) mode = *value >= REBASE_TRUE ? PULL_MODE_REBASE : PULL_MODE_MERGE;
Currently --rebase without argument overrides pull.rebase: git config pull.rebase merges git pull --rebase Up until now this hasn't been a big issue, since user has not been forced to specify a merge, or a rebase. But with the introduction of --merge and pull.mode, the user could in theory have the following configuration: git config pull.mode merge git config pull.rebase merges In such case, the user would expect: git pull --rebase To be the same as: git pull --rebase=merges If the user wants to override the configuration, she can do: git pull --rebase=true Cc: Tao Klerks <tao@klerks.biz> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- builtin/pull.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)