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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 30, 2018, 11:03 UTC
Message-ID: <nycvar.QRO.7.76.6.1808301259420.71@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqq5zzs94qb.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Wed, 29 Aug 2018, Junio C Hamano wrote:

Show 15 quoted lines

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > The builtin rebase and the builtin interactive rebase have been
> > developed independently, on purpose: Google Summer of Code rules
> > specifically state that students have to work on independent projects,
> > they cannot collaborate on the same project.
> 
> A much better description, especially without the less relevant "the
> reason probably is..." omitted from here.  The author's personal
> guess, while adding it does not help understanding what is already
> in the above paragraph an iota, is still a fine reading material in
> the cover letter 0/1, though.

I addressed Jonathan's concern, though.

Show 35 quoted lines

> > One fallout is that the rebase-in-c and rebase-i-in-c patches cause no
> > merge conflicts but a royal number of tests in the test suite to fail.
> >
> > It is easy to explain why: rebase-in-c was developed under the
> > assumption that all rebase backends are implemented in Unix shell script
> > and can be sourced via `. git-rebase--<backend>`, which is no longer
> > true with rebase-i-in-c, where git-rebase--interactive is a hard-linked
> > builtin.
> >
> > This patch fixes that.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  builtin/rebase.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 81 insertions(+)
> 
> 
> Will replace by doing:
> 
>     $ git checkout js/rebase-in-c-5.5-work-with-rebase-i-in-c
>     $ git checkout HEAD^
>     $ git am -s mbox
>     $ git range-diff @{-1}...
>     $ git checkout -B @{-1}
> 
>     $ git checkout pk/rebase-i-in-c-6-final
>     $ git rebase --onto js/rebase-in-c-5.5-work-with-rebase-i-in-c \
>           js/rebase-in-c-5.5-work-with-rebase-i-in-c@{1} HEAD^0
>     $ git range-diff @{-1}...
>     $ git checkout -B @{-1}
> 
> to update the two topics and then rebuilding the integration
> branches the usual way.  I also need to replace the "other" topic
> used in this topic, so the actual procedure would be a bit more
> involved than the above, though.

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

Ciao, Dscho