From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Documentation/config.txt: change "pull.rebase" description in favor of safer 'preserve' option.
Date: Tue, 05 Aug 2014 15:32:08 -0700 [thread overview]
Message-ID: <xmqqa97io9ef.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <87bnrzxhrm.fsf@osv.gnss.ru> (Sergey Organov's message of "Tue, 5 Aug 2014 14:58:29 +0400")
Sergey Organov <sorganov@gmail.com> writes:
> Previous description implicitly favored 'true' value for "pull.rebase"
> and "pull.<branch>.rebase" options,
I do not share that impression. It is true that 'true' is described
first before 'preserve', which can be argued that it is being
implicitly favoured, but we have to pick one over the other when
describing two things, so I do not see it as a strong preference.
> when for some workflows 'preserve'
> is the right choice, and for others it hardly makes any difference.
> Therefore, 'preserve' should be preferred in general, unless the user
> knows exactly what she is doing.
I doubt we saw any such conclusion in the recent thread that
discussed this, other than your repeating that statement---and I've
learned to tell repeated voices and chorus apart over time ;-).
One approach is more suitable for some workflows while being
inappropriate for others and that goes for both variants. A
downside of flattening is that it gives a wrong result when the user
wants to keep merges. Two downsides of preserving are that it gives
a wrong result when the user wants to flatten, and it tends to be
slower.
During that discussion, you seemed to assume that those who want a
flattened end result would never merge locally; I do not think that
is true. Having your own merges on a branch that you would want to
rebase to flatten is not unusual.
You may employ a workflow to build on separate topic branches while
developing, merge the topics among them that are ready into your
local 'master' to be used personally, and after using it from your
local 'master' for a while to make sure it is solid, you may decide
to make it final by publishing it to the outside world, and at that
point you would want to flatten the history on top of the latest
upstream before pushing. That's not anything advanced that takes "
the user knows exactly what she is doing."
next prev parent reply other threads:[~2014-08-05 22:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-05 10:58 [PATCH] Documentation/config.txt: change "pull.rebase" description in favor of safer 'preserve' option Sergey Organov
2014-08-05 22:32 ` Junio C Hamano [this message]
2014-08-06 10:29 ` Sergey Organov
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=xmqqa97io9ef.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sorganov@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.