On Fri, Dec 4, 2020 at 5:27 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Thu, Dec 3, 2020 at 10:16 PM Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: > > > > Previously --no-rebase (which still works for backwards compatbility). > > > > Now we can update the default warning, and the git-pull(1) man page to > > use --merge instead of the non-intuitive --no-rebase. > > > > Signed-off-by: Felipe Contreras <felipe.contreras@xxxxxxxxx> > > --- > > Documentation/git-pull.txt | 9 ++++++--- > > builtin/pull.c | 4 +++- > > t/t7601-merge-pull-config.sh | 4 ++-- > > 3 files changed, 11 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt > > index ad33d2472c..c220da143a 100644 > > --- a/Documentation/git-pull.txt > > +++ b/Documentation/git-pull.txt > > @@ -61,7 +61,7 @@ However, a non-fast-foward case looks very different. > > ------------ > > > > By default `git pull` will warn about these situations, however, most likely > > -you would want to force a merge, which you can do with `git pull --no-rebase`. > > +you would want to force a merge, which you can do with `git pull --merge`. > > I'm glad you updated all the references, but as noted earlier in the > series I think this suggestion is problematic. Yeah, but the danger comes straight from what "git pull" does by default (an implicit "git pull --merge"). It's not the text that is dangerous; it's the default behavior. -- Felipe Contreras
