From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 19 Jul 2013 22:55:57 GMT
Subject: Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
Message-ID: <7vip06tb0i.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAPig+cT83Zv5aDDTYhfLOQ-ymCckwHDhxE6ChHUQKWQbfPdG6A@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

>>     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].
>
> At this point, I'm probably just bike-shedding. Perhaps?
>
>     With no 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`.
>
>     To match a project's workflow and make the choice of merge or
>     rebase permanent, set configuration variable `pull.rebase` or
>     `branch.<name>.rebase` (see linkgit:git-config[1]).

I agree with the bike-shedding aspect of your comment, and actually
I like my version better.

It makes it clear that a single-shot --merge or --rebase from the
command line is not recommended.  "To match the project's workflow"
is not optional in most projects, and it is preferrable to decide
once and set the choice in stone.