All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: 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: Thu, 30 Aug 2018 13:03:41 +0200 (DST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1808301259420.71@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqq5zzs94qb.fsf@gitster-ct.c.googlers.com>

Hi Junio,

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

> "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.

> > 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


  reply	other threads:[~2018-08-30 11:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-22 21:35 [PATCH 0/1] Teach the builtin rebase about the builtin interactive rebase Johannes Schindelin via GitGitGadget
2018-08-22 21:35 ` [PATCH 1/1] builtin rebase: prepare for builtin rebase -i Johannes Schindelin via GitGitGadget
2018-08-22 21:50 ` [PATCH 0/1] Teach the builtin rebase about the builtin interactive rebase Junio C Hamano
2018-08-23  2:48 ` Jonathan Nieder
2018-08-25 23:46   ` Johannes Schindelin
2018-08-27 17:48     ` Junio C Hamano
2018-08-28 12:53       ` Johannes Schindelin
2018-08-28 15:34         ` Junio C Hamano
2018-08-29 13:24           ` Johannes Schindelin
2018-08-28 17:17         ` Jonathan Nieder
2018-08-29 14:29           ` Johannes Schindelin
2018-08-29 14:31 ` [PATCH v2 " Johannes Schindelin via GitGitGadget
2018-08-29 14:31   ` [PATCH v2 1/1] builtin rebase: prepare for builtin rebase -i Johannes Schindelin via GitGitGadget
2018-08-29 22:40     ` Junio C Hamano
2018-08-30 11:03       ` Johannes Schindelin [this message]
2018-08-30 20:09         ` Jeff King
2018-08-31 20:38           ` Johannes Schindelin
2018-08-31 20:48             ` Jeff King
2018-10-05 15:54   ` [PATCH v3 0/1] Teach the builtin rebase about the builtin interactive rebase Johannes Schindelin via GitGitGadget
2018-10-05 15:54     ` [PATCH v3 1/1] builtin rebase: prepare for builtin rebase -i Johannes Schindelin via GitGitGadget
2018-10-06 23:50     ` [PATCH v3 0/1] Teach the builtin rebase about the builtin interactive rebase Junio C Hamano
2018-10-12  7:59       ` Johannes Schindelin

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=nycvar.QRO.7.76.6.1808301259420.71@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /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.