git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: git@vger.kernel.org
Subject: Re: [RFC PATCH] rebase: implement --rewind
Date: Tue, 28 Mar 2023 18:11:18 +0200	[thread overview]
Message-ID: <ZCMRpnS9gzN1Rlbh@ugly> (raw)
In-Reply-To: <7bd63d7e-ad13-d5b8-54ea-ba5f81da0c17@gmx.de>

On Tue, Mar 28, 2023 at 04:53:52PM +0200, Johannes Schindelin wrote:
>I do not think that the concept in its
>current form mixes well with being in the middle of a `--rebase-merges`
>run.
>
fundamentally, it shouldn't pose a problem: the already done part leads 
up to a single commit, from which a complete todo with merges up to that 
point can be built again, while the remainder of the pre-existing todo 
should be unfazed by the fact that you're repeatedly messing with 
whatever branch you stopped in.
i *think* i even tried a few simple cases and found the result adequate, 
but i don't remember for sure (it's been a few months since i authored 
the patch).
just give it a shot.

>On the other hand, it might often be good enough to redo only the 
>commits
>between `onto` and `HEAD`, not the complete rebase script that's now in
>`done`. But then it does not strike me so much as "rewinding" but as
>"nesting.
>
according to the terminology i'm using, this still qualifies as a flat 
rewind, only that it limits itself to --first-parent. we'll see whether 
this turns out to be a necessary simplification, but i don't think so.

true nesting would mean that the rewind itself can be aborted, in case 
you change your mind back. adding that as an option on top of what i'm 
doing isn't a hard problem _per se_. you would need to figure out the 
challenges from my OP, though.
also note the reference in the OP; we discussed this here a while ago 
already.


  reply	other threads:[~2023-03-28 16:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 16:22 [RFC PATCH] rebase: implement --rewind Oswald Buddenhagen
2023-03-28 14:53 ` Johannes Schindelin
2023-03-28 16:11   ` Oswald Buddenhagen [this message]
2023-04-05 12:07     ` Johannes Schindelin
2023-04-05 15:15       ` Oswald Buddenhagen
2023-04-06 10:45         ` Ævar Arnfjörð Bjarmason
2023-04-06 14:49           ` Oswald Buddenhagen
2023-04-07  0:21           ` Felipe Contreras
2023-04-07  7:00             ` Oswald Buddenhagen
2023-04-11 10:06               ` Phillip Wood
2023-04-06 10:01       ` Phillip Wood

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=ZCMRpnS9gzN1Rlbh@ugly \
    --to=oswald.buddenhagen@gmx.de \
    --cc=git@vger.kernel.org \
    /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).