From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: Edmundo Carmona Antoranz <eantoranz@gmail.com>, git@vger.kernel.org
Subject: Re: [RFC/PATCH 1/2] rebuash - squash/rebase in a single step
Date: Tue, 2 Jul 2019 07:37:39 -0400 [thread overview]
Message-ID: <2cece7ff-49af-0cae-7cb8-7cc1821be1ca@gmail.com> (raw)
In-Reply-To: <xmqq36jp7gd8.fsf@gitster-ct.c.googlers.com>
On 7/1/2019 2:35 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>>> First, we create a (temporary) merge commit of both branches (M3)
>>>
>>> ------------
>>> R1---R2---R3---R4---R5---R6---R7---M3
>>> \ \ \ /
>>> F1---F2---M1---F3---F4---M2---F5
>>> ------------
>>>
>>> At this point, all differences between M3 and R7 are the changes related to the
>>> feature branch, so we can run git reset --soft from M3 to R7 to put all those
>>> differeces in index, and then we create single revision that is both
>>> squashed/rebased for our feature branch.
>>
>> So if I understand correctly, our goal is:
>>
>> R1--R2--...--R7--R8
>>
>> where R8 has the same tree as M3?
>>
>> Wouldn't doing "git merge --squash" do the same thing?
>
> Yup, from Edmundo's description, I agree that they are equivalent,
> modulo the merge direction.
[snip]
> If M3 merge is always easier to manage than incremental stepwise
> rebase of the topic, then doing the "git merge --reverse-squash"
> would be a saner interface and also conceptually simpler.
I agree that this would be a better way to expose this behavior,
and likely the implementation could be very clean.
Thanks,
-Stolee
next prev parent reply other threads:[~2019-07-02 11:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-30 5:18 [RFC/PATCH 1/2] rebuash - squash/rebase in a single step Edmundo Carmona Antoranz
2019-06-30 5:18 ` [RFC/PATCH 2/2] rebuash - support for status Edmundo Carmona Antoranz
2019-06-30 5:28 ` Edmundo Carmona Antoranz
2019-06-30 6:53 ` [RFC/PATCH 1/2] rebuash - squash/rebase in a single step Jeff King
2019-06-30 15:09 ` Edmundo Carmona Antoranz
2019-06-30 22:39 ` Jeff King
2019-07-01 1:37 ` Edmundo Carmona Antoranz
2019-07-01 18:50 ` Junio C Hamano
2019-07-01 20:48 ` Edmundo Carmona Antoranz
2019-07-01 18:35 ` Junio C Hamano
2019-07-02 11:37 ` Derrick Stolee [this message]
2019-07-02 17:20 ` Junio C Hamano
2019-07-02 19:30 ` Johannes Sixt
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=2cece7ff-49af-0cae-7cb8-7cc1821be1ca@gmail.com \
--to=stolee@gmail.com \
--cc=eantoranz@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.