Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull

[John Keeping <john@keeping.me.uk>]

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@pobox.com>
> ---
[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.