Hi Junio,
On Wed, 29 Aug 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@xxxxxx>
> >
> > 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.
> > 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@xxxxxx>
> > ---
> > 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
