git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Tokarev <annulen@yandex.ru>
To: Junio C Hamano <gitster@pobox.com>, Elijah Newren <newren@gmail.com>
Cc: Robert Dailey <rcdailey.lists@gmail.com>, Git <git@vger.kernel.org>
Subject: Re: Why does `pull.rebase` default to `false`?
Date: Sat, 29 Feb 2020 00:10:43 +0300	[thread overview]
Message-ID: <1320071582924243@iva6-ab1cb434301d.qloud-c.yandex.net> (raw)
In-Reply-To: <xmqq8skmeabd.fsf@gitster-ct.c.googlers.com>



28.02.2020, 23:17, "Junio C Hamano" <gitster@pobox.com>:
> Elijah Newren <newren@gmail.com> writes:
>
>>  On Fri, Feb 28, 2020 at 10:17 AM Robert Dailey <rcdailey.lists@gmail.com> wrote:
>>>  ...
>>>  I'm sure there are edge cases that explain why the default is `false`,
>>>  but I'd argue that it is likely a case of the minority concerns
>>>  becoming an inconvenience for the majority of users.
>>>
>>>  Thanks in advance for any enlightenment!
>>
>>  The default of pull.rebase being false makes a lot of sense for Linus
>>  or any of his lieutenants, or any one else in an integrator-like
>>  workflow.
>>  ...
>>  We may want to do something similar with pull.rebase (only let it
>>  succeed if it's a fast-forward by default, otherwise require the user
>>  to set pull.rebase first?), but I don't want to have to think through
>>  the details or work on such a transition -- I'm just commenting with
>>  some thoughts that might help you understand the current state. And
>>  others probably have more details than me.
>
> While it is true that it would make no sense for integrators to
> rebase (in fact it would be a grave sin for them to do so), I do
> not think the choice of the default has much to do with it.
>
> Whether you keep your work on topic branches, or you only work on a
> single thing at a time and use master for it, an individual
> contributor who is working on a project (be it small or large) can
> do 'pull --rebase' on each topic branch to keep up with the updated
> upstream, but it quickly becomes unpleansant once the topics start
> to get interrelated. And at that point, leaving your 'master' clean
> and only run "pull --ff-only" there, and after doing it once,
> rebasing your multiple topics locally on top of the updated upstream
> (or your 'master', which is a clean copy of it), would start to make
> more sense. And once you start doing that, the only 'pull' you'd do
> would be 'pull --ff-only', and at that point the default value of
> pull.rebase no longer matters.
>
> Sarcastically put, setting pull.rebase=true may become a way to
> ensure that a newbie stays a newbie who does not learn to juggle
> multiple related branches, because only the simplest thing becomes
> easier with the setting.

In reality, newbies often end up doing chaotic merges caused by pull
instead of learning about rebase and branches. IMO, it would be better
to have pull.ff=only as a default.



-- 
Regards,
Konstantin


  reply	other threads:[~2020-02-28 21:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28 18:15 Why does `pull.rebase` default to `false`? Robert Dailey
2020-02-28 18:54 ` Randall S. Becker
2020-02-28 18:56 ` Elijah Newren
2020-02-28 20:17   ` Junio C Hamano
2020-02-28 21:10     ` Konstantin Tokarev [this message]
2020-02-28 21:22       ` Robert Dailey
2020-02-28 21:46         ` Konstantin Tokarev
2020-02-28 21:53         ` Alex Henrie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1320071582924243@iva6-ab1cb434301d.qloud-c.yandex.net \
    --to=annulen@yandex.ru \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=rcdailey.lists@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).