On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Linus Torvalds <torva...@linux-foundation.org> writes:
>> It would be a *horrible* mistake to make "rebase" the default, because
>> it's so much easier to screw things up that way.
>> That said, making "no-ff" the default, and then if that fails, saying
>> The pull was not a fast-forward pull, please say if you want to
>> merge or rebase.
>> Use either
>> git pull --rebase
>> git pull --merge
>> You can also use "git config pull.merge true" or "git config
>> pull.rebase true"
>> to set this once for this project and forget about it.
>> That way, people who want the existing behavior could just do that
>> git config pull.merge true
>> once, and they'd not even notice.
>> Hmm? Better yet, make it per-branch.
> I would assume that "no-ff" above was meant to be "--ff-only" from
> the first part of the message.
> I also would assume that I can rephrase that setting pull.merge
> (which does not exist) as setting pull.rebase explicitly to false
> instead (i.e. missing pull.rebase and pull.rebase that is explicitly
> set to false would mean two different things).
> I have to think about this a bit to convince myself that the message
> is clear enough and useful for those this updated behaviour is
> trying to help. After reading the above message three times, I
> still cannot shake the impression that we are just covering our
> backside to be able to say "we told you already and you chose
> poorly", in case things go wrong for them later.
FWIW this is the message Mercurial users get (and they often say
Mercurial's UI makes more sense):
pushing to /tmp/foo
searching for changes
abort: push creates new remote head 77eafc4313d5!
(you should pull and merge or use push -f to force)
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