Re: [PATCH v2 1/1] builtin rebase: prepare for builtin rebase -i

From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2 1/1] builtin rebase: prepare for builtin rebase -i
Date: Fri, 31 Aug 2018 16:48:32 -0400	[thread overview]
Message-ID: <20180831204832.GA14869@sigill.intra.peff.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1808312238250.71@tvgsbejvaqbjf.bet>

On Fri, Aug 31, 2018 at 10:38:44PM +0200, Johannes Schindelin wrote:

> > > Is there any reason why you avoid using `git rebase -ir` here? This should
> > > be so much easier via
> > > 
> > > 	git checkout pk/rebase-i-in-c-6-final
> > > 	git rebase -ir js/rebase-in-c-5.5-work-with-rebase-i-in-c^
> > > 
> > > and then inserting this at the appropriate position, followed by the `git
> > > range-diff @{-1}...`:
> > > 
> > > 	git am -s mbox
> > > 	git update-ref js/rebase-in-c-5.5-work-with-rebase-i-in-c HEAD
> > 
> > Related discussion, including a fantasy tangent by me (downthread):
> > 
> >   https://public-inbox.org/git/20180727080807.GA11932@sigill.intra.peff.net/#t
> 
> I have no idea what you meant there...

I thought you were asking why Junio does not just use "git am" from
inside "git rebase". I asked the same thing recently, and the answer is
because he is afraid of how the two interact. I dug a little into it
(the fantasy part is that I laid out a dream for how operations like
this could safely stack).

-Peff