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 <gits...@pobox.com>
> ---
> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to