Description of problem: Cloning a repository and then doing a pull generates the following message: 'warning: Pulling without specifying how to reconcile divergent branches is discouraged. ...' Version-Release number of selected component (if applicable): git version 2.28.0 How reproducible: Every time with multiple repositories. Steps to Reproduce: 1: git clone https://github.com/githubtraining/hellogitworld.git hellogitworld.git 2: cd hellogitworld.git 3: git pull Actual results: warning: Pulling without specifying how to reconcile divergent branches is discouraged. ... Expected results: Already up to date. Additional info: The test above geneates the expected results using Fedora 32 with git 2.26.2
This is expected behaviour. The warning doesn't prevent the pull from occurring, it just lets you know that you should choose which rebase strategy to use. The current default strategy is merge, which isn't really what most users should likely use. Adding the warning will allow a future version of git to change the default. Whether and when that may happen is not set in stone, AFAIK. Following the recommendations in the output is the intended way to silence this output.
1. If the current local hash is in the history for the remote branch, it should not matter what strategy is used because the results will be the same ? 2. I the case reported above, the hash for the local and remote branch were the same, so it surely does not matter what strategy is used. So the warning was confusing (to me). 3. If the default strategy has not changed, a message that would be less confusing (to me) is: 'Using pull without a merge strategy has been deprecated' and then go on to explain what users should do. Saying that the pull has been deprecated explains (to me) that the result has not changed (yet).
(In reply to Brad Bell from comment #2) > 1. If the current local hash is in the history for the remote branch, it > should not matter what strategy is used because the results will be the same > ? > > 2. I the case reported above, the hash for the local and remote branch were > the same, so it surely does not matter what strategy is used. So the warning > was confusing (to me). I can understand that. The reason the warning is given regardless of whether any changes were made is that it is warning that you've used `git pull` without specifying how changes would be handled. It's a blanket warning any time a user runs `git pull` and has not specified an option. > 3. If the default strategy has not changed, a message that would be less > confusing (to me) is: > 'Using pull without a merge strategy has been deprecated' and then go on to > explain what users should do. > Saying that the pull has been deprecated explains (to me) that the result > has not changed (yet). Is saying it is "deprecated" much different or better than saying it is "discouraged" though? (I'm not sure that it is "deprecated" in a strict technical sense, so that's possibly why it's worded as it is.) The rest of the message does show what the current default is (merge). Ideally, users seeing the message who are unsure what value they should use for `pull.rebase` would check the `git-config(1)` and/or `git-pull(1)` documentation and choose what's appropriate for their usage. It's almost always true that the documentation for each could be improved, but I'm not sure offhand what such an improvement might look like. It may be worth bringing this up on the git mailing list (git AT vger.kernel.org) to see if anyone there has thoughts on the matter. It's often useful to get the perspective of folks who aren't regular readers of the list. FWIW, the change was made in 2.27.0 (released in May), so it's had a bit of time in the wild without many complaints (to my recollection of the list traffic). But even if that's the case, it doesn't mean that it's perfect, by any means.
Not that I am going to join the upstream discussion, but since I noticed this, I agree that the warning is totally unexpected. I don't know what was the strategy previously but I know I never needed to think about it and so far so good. Not sure why I should bother to understand now ...
https://github.com/git/git/commit/d18c950a69 is the commit which added the warning. It contains the brief rationale. The default has long been false, which creates a merge commit (when there are changes on both the local and remote branches). This is generally not the best option for many users. This merge commit is useless noise in the public history. Many users and upstream projects prefer to avoid such noise merges. For anyone relying on the current `pull.rebase` default (false, which results in a merge), the reason they should bother to understand it is so they can choose a suitable `pull.rebase` setting for their projects. For most users, merging is the least appropriate option of those those available. That could potentially be changed in the future. To make it easier for anyone to catch up on the upstream discussions on this patch, they're at: https://lore.kernel.org/git/20200228215833.319691-1-alexhenrie24@gmail.com/ - v1 https://lore.kernel.org/git/20200229010927.335119-1-alexhenrie24@gmail.com/ - v2 https://lore.kernel.org/git/20200229212258.373891-1-alexhenrie24@gmail.com/ - v3 https://lore.kernel.org/git/20200304022931.2469455-1-alexhenrie24@gmail.com/ - v4 https://lore.kernel.org/git/20200310035420.1658876-1-alexhenrie24@gmail.com/ - v5 I hope that anyone who wishes to improve it will take that discussion upstream.
I started the thread here: https://public-inbox.org/git/742df4c2-2bc5-8a4b-8de1-cd5e48718398@redhat.com/T/#u