Recently I've been seeing this warning while updating the feeds. I know these warnings can disappear when configuring git, but shouldn't these be configured by default in the script, so anyone with a clean config not get these errors?
Updating feed 'packages' from 'https://git.openwrt.org/feed/packages.git' ...
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:
git config pull.rebase false # merge (the default strategy)
git config pull.rebase true # rebase
git config pull.ff only # fast-forward only
You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
That's a client side warning, caused by your git client updating. Now it's your turn to make a decision how your git clients is supposed to deal with rebasing (the help messages should be self-explaining, to set the marked default strategy globally).
For casual users (who are not doing own commits to local feed repos), the easiest might be to silence the warning (in git 2.27+) by patching "scripts/feeds" to specify "ff-only".
I have done that, and I have also considered submitting a patch about that.
@@ -158,8 +158,8 @@ my %update_method = (
'init' => "git clone --depth 1 '%s' '%s'",
'init_branch' => "git clone --depth 1 --branch '%s' '%s' '%s'",
'init_commit' => "git clone '%s' '%s' && cd '%s' && git checkout -b '%s' '%s' && cd -",
- 'update' => "git pull --ff",
- 'update_force' => "git pull --ff || (git reset --hard HEAD; git pull --ff; exit 1)",
+ 'update' => "git pull --ff-only",
+ 'update_force' => "git pull --ff-only || (git reset --hard HEAD; git pull --ff-only; exit 1)",
'post_update' => "git submodule update --init --recursive",
'controldir' => ".git",
'revision' => "git rev-parse --short HEAD | tr -d '\n'"},
This is what I was thinking, since the script wants and is supposed to do a fast-forward, this should be clearly specified in the script files, to let anyone with the default config be free of these messages.
My point of view is that the script should be specific to what it wants to do and not let it hang in the air or be defined by the user.
Since this script was in perl and I know nothing of it will you submit this pull request?
I have so far hesitated with the PR, as I have been thinking if "ff-only" is really the best option.
It suits my own workflow, as I keep my own source changes uncommitted, which leads to "git stash, git pull, git stash pop" workflow when there are conflicts.
But "ff rebase" might work better for those who commit their changes. Then I would need to do the same, but those with local change commits could get pull with their own changes rebased, if possible.
Ideologically "ff-only" is the purest, as all local changes need to be handled manually.
So, as someone who has contributed some times (not many, but some) I usually only change stuff in that branch temporarily and then move the edited stuff back to my fork and commit them.
Since I believe this feed shouldn't be used for personal commits there is no harm in fast forward since we assume that we will update a older version of upstream and not a modified on correct?