Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Philip Oakley <philipoakley@iee.email>
To: George Spelvin <lkml@SDF.ORG>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: Feature request: rebase -i inside of rebase -i
Date: Mon, 30 Mar 2020 22:53:05 +0100
Message-ID: <8f6fb826-7f9f-57ea-725f-dc3c512a4b18@iee.email> (raw)
In-Reply-To: <20200330181812.GB9199@SDF.ORG>

Hi George,

I wasn't suggesting that there already exists a complete solution...

On 30/03/2020 19:18, George Spelvin wrote:
> On Mon, Mar 30, 2020 at 03:01:28PM +0100, Philip Oakley wrote:
>> Perhaps we can go the other way on this one.
>>
>> I'd agree that attempting to nest (misunderstood mistaken) rebases is
>> digging a too deep hole that we'd not get out of. However we do have
>> other rebases available, specifically the "rebasing merges"
>> https://git-scm.com/docs/git-rebase#_rebasing_merges.

I was mainly saying that folks like their "all on one page, flow chart
sequence planning", and that we already have something close to that
that could be extended.  
>>
>> I know rebasing merges is way down the man page, but it has all the
>> power and flexibility needed _if_ we can step across from the mistaken
>> rebase step (we are at the command prompt aren't we?) into the rebasing
>> merge mode.
>>
>> This will require a little bit of expansion of the insn (instruction)
>> sheet so as to _include commented lines of the rebase steps completed_
>> so far, along with the labels, resets, merges, etc, so that the user can
>> _see_ where they they are within their failed progress (along with a
>> title line telling them their initial command and that they are now on a
>> rebasing merge insn;-).
>>
>> From there they can update the insn to reset back to the correct point,
>> redo the correct picks, and then get back to their remaining rebase steps.
>>
>> It's a thought anyway.
> I'm confused.  *How* does --rebase-merge mode help?  You're saying
> "hey, if we use this, it solves the issue" but I don't see how to
> pound this nail with that screwdriver.
Remember that rebasing is just a variant of creating and building a new
branch in our WORM (Write once Read many) repo..
So it is "just" a case of taking the partially complete rebase, and
re-working it, just like you can with an arbitrary merging rebase.
>
> I don't see how creating a branching history helps, and I don't see how to 
> use the reset/label/merge commands to do anything but create a branching 
> history.

It is more that we could create a full instruction sheet that spans time
from the start of the rebase (including labelling and resetting to get
started), upto and including the current state (so you can pick from
your new commits[*]), with those history steps being hash "#" commented,
as well as the remaining rebase instructions.
> I suppose it is possible to use the "reset" command in isolation
> to describe the jump to a new base.  So you could have a history of:
>
> # Command already executed:
#git rebase <command options> (for reference & immediate use)
> # reset base
> # pick A
> # pick B
> # pick C
> # label rebase-1  User asked for a nested rebase
> # reset A'
[*] We are missing a list of the current state of new commits,
# reset base (done, see above)
# placed A' (you'll need this listed if you need to pick/edit/reword
#  You are now at deadbeef, rebasing 23 of 75 commits .... (..suitable
status message)


> # Commands pending:
> pick B'
> pick C'
> # rebase-2 complete, resume rebase-1
> pick D
> pick E
>
> Is that what you were getting at?

Correct. Given the global state problem, and the mental picture issues,
let's give the user a full picture, flow chart style (it's a solid old
technique that works well, even for beginners)
>
> I was thinking of it being implicit, but it might be nice for the initial
> "reset" in each rebase to be explicit, *and not yet executed during
> the initial todo edit*.
>
> That makes it really clear that deleting the todo list entirely
> results in no change to the tree. (folks rarely notice omissions, we'll still need to tell them that it's a valid solution! sometimes empty means 'no change, carry on what you were doing';-)

Philip

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20 22:30 George Spelvin
2020-03-20 22:51 ` Junio C Hamano
2020-03-20 23:35   ` George Spelvin
2020-03-21 10:51     ` Johannes Schindelin
2020-03-21 17:56       ` George Spelvin
2020-03-25 19:26         ` Johannes Schindelin
2020-03-26  0:18           ` George Spelvin
2020-03-28 14:25             ` Johannes Schindelin
2020-03-28 16:30               ` George Spelvin
2020-03-31  0:00                 ` George Spelvin
2020-03-31 10:57                   ` Philip Oakley
2020-03-31 13:36                     ` Phillip Wood
2020-04-01 16:43                       ` Philip Oakley
2020-04-07 15:54                         ` Phillip Wood
2020-04-04 12:17                   ` Johannes Schindelin
2020-04-04 12:39                 ` Johannes Schindelin
2020-04-04 17:41                   ` George Spelvin
2020-04-06 10:40                     ` Sebastien Bruckert
2020-04-06 15:24                       ` George Spelvin
2020-04-07  9:16                         ` Sebastien Bruckert
2020-04-07 19:03                           ` George Spelvin
2020-03-30 14:01               ` Philip Oakley
2020-03-30 18:18                 ` George Spelvin
2020-03-30 21:53                   ` Philip Oakley [this message]
2020-03-21  8:47 ` Johannes Sixt

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=8f6fb826-7f9f-57ea-725f-dc3c512a4b18@iee.email \
    --to=philipoakley@iee.email \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=lkml@SDF.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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git