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

From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>, John Keeping <john@keeping.me.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andreas Krey <a.krey@gmx.de>,
	John Szakmeister <john@szakmeister.net>,
	Andreas Schwab <schwab@linux-m68k.org>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
Date: Fri, 19 Jul 2013 15:20:09 -0700	[thread overview]
Message-ID: <7vzjtitco6.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAPig+cQEtKc+tfDgqVWYL2JtxXc=wvS=P7_O=XJzizz1BN=n4A@mail.gmail.com> (Eric Sunshine's message of "Fri, 19 Jul 2013 16:29:20 -0400")

Eric Sunshine <sunshine@sunshineco.com> writes:

> Dropping the parenthetical comment might improve flow slightly:
>
>     Without repository or branch on the command line, `git pull`
>     needs to be told how to integrate the changes with your history,
>     via either `--merge` or `--rebase`.
>
> With or without mention of the configuration options, either phrasing
> seems pretty easy to digest.

Yeah, that reads much better, but I do prefer to see something that
explains this is often "just make sure you use the one that suits
your project and always use that".  How about something like this?

    With no repository or branch on the command line, `git pull` needs
    to be told how to integrate the changes with your history.

    This can be done via either `--merge` or `--rebase` option, but most
    people would want to decide which method matches the workflow of the
    project once, and set the configuration variable `pull.rebase` or
    `branch.<name>.rebase` to stick to it; see linkgit:git-config[1].