On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: > Because letting a trivial merge automatically handled by Git is so > easy with "git pull", a person who is new to Git may not realize > that the project s/he is interacting with may prefer "rebase" > workflow. Add a safety valve to fail "git pull" that is not a > fast-forward until/unless the user expressed her preference between > the two. > > Those who want the existing behaviour could just do > > git config --global pull.rebase false > > once, and they'd not even notice. > > http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326 > > for a full discussion. > > The fallout from this change to test suite is not very pretty, though. > > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- [snip] > diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh > index c56a77d..af02c6d 100644 > --- a/t/annotate-tests.sh > +++ b/t/annotate-tests.sh > @@ -79,7 +79,7 @@ test_expect_success \ > > test_expect_success \ > 'merge-setup part 3' \ > - 'git pull . branch1' > + 'git pull --merge . branch1' I think the "--merge" should be implied here because the suer has specified an explicit remote and branch. Similarly, if "--ff", "--no-ff" or "--ff-only" are given then we can infer "--merge" in the absence of any other configuration. However, when I looked at doing this I decided that it would be difficult to get that ideal behaviour without rewriting git-pull as a builtin. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html