git/builtin/pull.c, branch v2.32.2

pull: display default warning only when non-ff

2020-12-16T01:39:42Z

There's no need to display the annoying warning on every pull... only the ones that are not fast-forward. The current warning tests still pass, but not because of the arguments or the configuration, but because they are all fast-forward. We need to test non-fast-forward situations now. Suggestions-by: Junio C Hamano Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

pull: correct condition to trigger non-ff advice

2020-12-16T01:39:42Z

Refactor the advise() call that teaches users how they can choose between merge and rebase into a helper function. This revealed that the caller's logic needs to be further clarified to allow future actions (like "erroring out" instead of the current "go ahead and merge anyway") that should happen whether the advice message is squelched out. Signed-off-by: Junio C Hamano

pull: get rid of unnecessary global variable

2020-12-16T01:39:17Z

It is easy enough to do, and gives a more descriptive name to the variable that is scoped in a more focused way. Signed-off-by: Junio C Hamano

pull: give the advice for choosing rebase/merge much later

2020-12-14T17:03:17Z

Eventually we want to be omit the advice when we can fast-forward in which case there is no reason to require the user to choose between rebase or merge. In order to do so, we need to delay giving the advice up to the point where we can check if we can fast-forward or not. Additionally, config_get_rebase() was probably never its true home. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

pull: refactor fast-forward check

2020-12-14T16:59:40Z

We would like to be able to make this check before the decision to rebase is made in a future step. Besides, using a separate helper makes the code easier to follow. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

Merge branch 'pb/pull-rebase-recurse-submodules'

2020-12-03T08:18:06Z

"git pull --rebase --recurse-submodules" checked for local changes in a wrong range and failed to run correctly when it should. * pb/pull-rebase-recurse-submodules: pull: check for local submodule modifications with the right range t5572: describe '--rebase' tests a little more t5572: add notes on a peculiar test pull --rebase: compute rebase arguments in separate function

Merge branch 'js/pull-rebase-use-advise'

2020-11-30T22:49:42Z

UI improvement. * js/pull-rebase-use-advise: pull: colorize the hint about setting `pull.rebase`

pull: colorize the hint about setting `pull.rebase`

2020-11-19T22:13:30Z

In d18c950a69f (pull: warn if the user didn't say whether to rebase or to merge, 2020-03-09), a new hint was introduced to encourage users to make a conscious decision about whether they want their pull to merge or to rebase by configuring the `pull.rebase` setting. This warning was clearly intended to advise users, but as pointed out in https://lore.kernel.org/git/87ima2rdsm.fsf%40evledraar.gmail.com, it uses `warning()` instead of `advise()`. One consequence is that the advice is not colorized in the same manner as other, similar messages. So let's use `advise()` instead. Pointed-out-by: Ævar Arnfjörð Bjarmason Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

pull: check for local submodule modifications with the right range

2020-11-17T00:01:13Z

Ever since 'git pull' learned '--recurse-submodules' in a6d7eb2c7a (pull: optionally rebase submodules (remote submodule changes only), 2017-06-23), we check if there are local submodule modifications by checking the revision range 'curr_head --not rebase_fork_point'. The goal of this check is to abort the pull if there are submodule modifications in the local commits being rebased, since this scenario is not supported. However, the actual range of commits being rebased is not 'rebase_fork_point..curr_head', as the logic in 'get_rebase_newbase_and_upstream' reveals, it is 'upstream..curr_head'. If the 'git merge-base --fork-point' invocation in 'get_rebase_fork_point' fails to find a fork point between the current branch and the remote-tracking branch we are pulling from, 'rebase_fork_point' is null and since 4d36f88be7 (submodule: do not pass null OID to setup_revisions, 2018-05-24), 'submodule_touches_in_range' checks 'curr_head' and all its ancestors for submodule modifications. Since it is highly likely that there are submodule modifications in this range (which is in effect the whole history of the current branch), this prevents 'git pull --rebase --recurse-submodules' from succeeding if no fork point exists between the current branch and the remote-tracking branch being pulled. This can happen, for example, when the current branch was forked from a commit which was never recorded in the reflog of the remote-tracking branch we are pulling, as the last two paragraphs of the "Discussion on fork-point mode" section in git-merge-base(1) explain. Fix this bug by passing 'upstream' instead of 'rebase_fork_point' as the 'excl_oid' argument to 'submodule_touches_in_range'. Reported-by: Brice Goglin Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

pull --rebase: compute rebase arguments in separate function

2020-11-17T00:01:13Z

The function 'run_rebase' is responsible for constructing the command line to be passed to 'git rebase'. This includes both forwarding pass-through options given to 'git pull' as well computing the and arguments to 'git rebase'. A following commit will need to access the argument in 'cmd_pull' to fix a bug with 'git pull --rebase --recurse-submodules'. In order to do so, refactor the code so that the and commits are computed in a new, separate function, 'get_rebase_newbase_and_upstream'. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano