From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Paul Morelle <paul.morelle@gmail.com>,
Git Users <git@vger.kernel.org>
Subject: Re: [PATCH] rebase -i: introduce the 'test' command
Date: Tue, 4 Dec 2018 10:13:24 +0100 (STD) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1812041007070.41@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20181203213134.GD8700@sigill.intra.peff.net>
Hi Peff,
On Mon, 3 Dec 2018, Jeff King wrote:
> On Mon, Dec 03, 2018 at 08:01:44PM +0100, Johannes Schindelin wrote:
>
> > > In this sort of situation, I often whish to be able to do nested rebases.
> > > Even more because it happen relatively often that I forget that I'm
> > > working in a rebase and not on the head, and then it's quite natural
> > > to me to type things like 'git rebase -i @^^^' while already rebasing.
> > > But I suppose this has already been discussed.
> >
> > Varieties of this have been discussed, but no, not nested rebases.
> >
> > The closest we thought about was re-scheduling the latest <n> commits,
> > which is now harder because of the `--rebase-merges` mode.
> >
> > But I think it would be doable. Your idea of a "nested" rebase actually
> > opens that door quite nicely. It would not *really* be a nested rebase,
> > and it would still only be possible in interactive mode, but I could
> > totally see
> >
> > git rebase --nested -i HEAD~3
> >
> > to generate and prepend the following lines to the `git-rebase-todo` file:
> >
> > reset abcdef01 # This is HEAD~3
> > pick abcdef02 # This is HEAD~2
> > pick abcdef03 # This is HEAD~
> > pick abcdef04 # This is HEAD
> >
> > (assuming that the latest 3 commits were non-merge commits; It would look
> > quite a bit more complicated in other situations.)
>
> Yeah, I would probably use that if it existed.
I kind of use it, even if it does not exist ;-)
> It would be nicer to have real nested sequencer operations, I think, for
> other situations.
I agree. But for the moment, our data format is too married to the exact
layout of .git/, thanks to `git rebase`'s evolution from a Unix shell
script.
Alban has this really great patch series to work on the todo list
in-memory, and that paves the way to decouple the entire sequencer thing
from the file system.
The most notably thing that still would need to be encapsulated would be
the options: currently, there is a plethora of inconsistent options files
being saved into the state directory (for some, the mere presence
indicates `true`, some contain `true` or `false`, others contain text,
etc).
> E.g., cherry-picking a sequence of commits while you're in the middle of
> a rebase.
You will be delighted to learn that you can cherry-pick a sequence of
commits in the middle of a rebase already. I do `exec git cherry-pick
<range>` *all* the time.
> But I suspect getting that right would be _loads_ more work, and
> probably would involve some funky UI corner cases to handle the stack of
> operations (so truly aborting a rebase may mean an arbitrary number of
> "rebase --abort" calls to pop the stack). Your suggestion is probably a
> reasonable trick in the meantime.
You know what is an even more reasonable trick? Worktrees.
I only thought about that this morning, but I should have mentioned it
right away, as I use it quite frequently.
When I have tricky nested rebases to perform, I do use throw-away
worktrees where I check out unnamed branches, work on those, and then
integrate them back into the "outer rebase" via the `reset` command in the
todo list.
Ciao,
Dscho
next prev parent reply other threads:[~2018-12-04 9:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-28 13:28 [PATCH] rebase -i: introduce the 'test' command Paul Morelle
2018-11-28 15:19 ` Johannes Schindelin
2018-11-28 16:56 ` Paul Morelle
2018-11-29 8:32 ` Johannes Schindelin
2018-11-29 10:55 ` Johannes Schindelin
2018-12-01 20:02 ` Jeff King
2018-12-02 2:28 ` Eric Sunshine
2018-12-02 3:31 ` Jeff King
2018-12-11 12:40 ` Ævar Arnfjörð Bjarmason
2018-12-11 14:11 ` Jeff King
2018-12-02 19:48 ` Johannes Schindelin
2018-12-03 14:31 ` Phillip Wood
2018-12-03 21:27 ` Jeff King
2018-12-03 17:27 ` Luc Van Oostenryck
2018-12-03 19:01 ` Johannes Schindelin
2018-12-03 19:34 ` Luc Van Oostenryck
2018-12-03 21:31 ` Jeff King
2018-12-04 9:13 ` Johannes Schindelin [this message]
2018-12-03 17:53 ` Duy Nguyen
2018-12-03 19:03 ` Johannes Schindelin
2018-12-03 21:34 ` Jeff King
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
List information: http://vger.kernel.org/majordomo-info.html
* 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.1812041007070.41@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=paul.morelle@gmail.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).