From: Junio C Hamano <gitster@pobox.com>
To: Alex Henrie <alexhenrie24@gmail.com>
Cc: git@vger.kernel.org, tao@klerks.biz, newren@gmail.com,
phillip.wood123@gmail.com, Johannes.Schindelin@gmx.de
Subject: Re: [PATCH 1/2] rebase: add a --rebase-merges=drop option
Date: Mon, 20 Feb 2023 13:42:02 -0800 [thread overview]
Message-ID: <xmqqr0ukggk5.fsf@gitster.g> (raw)
In-Reply-To: <20230220033224.10400-1-alexhenrie24@gmail.com> (Alex Henrie's message of "Sun, 19 Feb 2023 20:32:23 -0700")
Alex Henrie <alexhenrie24@gmail.com> writes:
> Name the new option "drop" intead of "no" or "false" to avoid confusion
This is traditionally called "flattening the history". Don't we
confuse uesrs by introducing a new phrase?
rebase-merges is about transplanting the history without flattening,
i.e. keeping the mergy commit graph topology. If there are only two
kinds of rebase (i.e. keeping the topology which is rebase-merges
and the other "flattening" kind) operation, shouldn't the option be
called "--no-rebase-merges" instead? --rebase-merges=no is also
understandable.
> in the future if --rebase-merges grows the ability to truly "rebase"
> merge commits by reusing the conflict resolution information from the
> original merge commit, and we want to add an option to ignore the
> conflict resolution information.
I am not sure why such a change "in the future" is not merely a
bugfix of the current "--rebase-merges", though. Once it is fixed,
is there a reason to make the fixed behaviour only available behind
an option?
next prev parent reply other threads:[~2023-02-20 21:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-20 3:32 [PATCH 1/2] rebase: add a --rebase-merges=drop option Alex Henrie
2023-02-20 3:32 ` [PATCH 2/2] rebase: add a config option for --rebase-merges Alex Henrie
2023-02-20 9:38 ` Phillip Wood
2023-02-20 17:06 ` Alex Henrie
2023-02-20 16:41 ` Elijah Newren
2023-02-20 9:31 ` [PATCH 1/2] rebase: add a --rebase-merges=drop option Phillip Wood
2023-02-20 17:03 ` Alex Henrie
2023-02-20 21:42 ` Junio C Hamano [this message]
2023-02-21 16:08 ` Philip Oakley
2023-02-21 18:42 ` Junio C Hamano
2023-05-13 16:51 ` [PATCH 0/1] cover-letter: flatten Philip Oakley
2023-05-13 16:56 ` [PATCH 1/1] doc: Glossary, describe Flattening Philip Oakley
2023-05-15 6:59 ` Junio C Hamano
2023-05-27 16:28 ` Philip Oakley
2023-05-19 21:35 ` Kristoffer Haugsbakk
2023-05-27 16:46 ` Philip Oakley
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=xmqqr0ukggk5.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=alexhenrie24@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=tao@klerks.biz \
/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.