Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Philip Oakley <philipoakley@iee.email>
To: phillip.wood@dunelm.org.uk, George Spelvin <lkml@SDF.ORG>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Feature request: rebase -i inside of rebase -i
Date: Wed, 1 Apr 2020 17:43:33 +0100
Message-ID: <60cd00c2-7aba-3d74-11fa-d4443f6cd83e@iee.email> (raw)
In-Reply-To: <ef1a1475-45b3-8696-ed1e-b28f7b655ece@gmail.com>

Hi Phillip,

On 31/03/2020 14:36, Phillip Wood wrote:
> Hi Philip, George and Johannes
>
> I really like the idea of being able to extend or rewind an existing
> rebase to reedit commits.
>
> On 31/03/2020 11:57, Philip Oakley wrote:
>> Hi george,
>>
>> On 31/03/2020 01:00, George Spelvin wrote:
>>> Thinking about Philip Oakley's suggestion, it dawned on me that
>>> we can *already* do a nested rebase manually, and having a less
>>> manual alias for the procedure would be reasonable.
>>>
>>> Suppose the last four commits are O-A-B-C, and whether they were
>>> created
>>> by this rebase or existed before is irrelevant.
>>>
>>> If I want to rebase --nested -i O, then I --edit-todo and
>>
>> Maybe `--rework` as a possible alternate option name, if the concept of
>> it being truly nested process does not work out?
>
> or `--rewind` ?

A possibility, though it feels a bit narrow in suggesting the capabilities
>
>>> prepend the following four lines:
>>> reset O
>>> pick A
>>> pick B
>>> pick C
>>>
>>> If a nested rebase command does just that, I think it would cover my
>>> use case.  If it adds a comment saying "nested rebase ends here",
>>> it's easy to cancel the nested rebase if there was a mistake.
>>>
>>> A slightly fancier thing a nestrd rebase could do is see if any of the
>>> newly created picks are also used in merges that were already in the
>>> todo
>>> list.  In that case, follow the pick by a label command and update the
>>> later merge to refer to the label.
>
> If we're going to support rewinding a rebase that creates merges then
> this is a prerequisite otherwise it wont work properly. It will also
> need to update any existing labels that refer to a commits that get
> rewritten when rewinding.

I would agree that the `label` instruction would need expanding to allow
arbitrary refs (e.g. specific oids and other branches) to be labelled
rather than just a presumed 'HEAD' ref. I did notice the man page
doesn't actually define the format of the extra instructions (there was
fun with awkward chars in label names on Windows).

I'm of the opinion that we don't re-label/rename the previous labels -
they are what they are, but we do offer the ability to provide new
labels. Hence the extension to the label format to allow the labelling
of arbitrary refs, not just HEAD, along with showing existing progress,
so folks can _see_ the new oids etc.
>
> When cancelling the nested rebase we need to take care to restore any
> labels to their previous value if they have been updated by the nested
> rebase. We also need to restore the list or rewritten commits so that
> we don't report that we've rewritten the commits from the nested
> rebase that we're aborting. These two requirements unfortunately make
> it difficult to implement the nested rebase just by updating the todo
> list. 

I'm against the original conceptual idea of 'nesting' (or rewinding).
What's done is done, it's in the object store, as is all the old
original work, so we have a wider foundation to build from.  Clearly we
are not in a clean work-state, with the half complete jobs, so it's more
of a recovery activity than clean coding (from the user perspective).

> It needs to save the current labels (and reference the commits
> somewhere so they don't get gc'd) and the rewritten-list. `git rebase
> --abort` (or whatever we end up using to abort the nested part of the
> rebase) needs to restore the labels and rewritten-list. I think it
> should probably restore the todo list as well - if the original part
> of the todo list gets edited during the nested rebase should we drop
> those changes to the list or keep them when the nested rebase is aborted?

If we haven't aborted, then we just have the actual sequence of work,
with some of the commits, ultimately, being left as unconnected stubs
(once their temporary tips have gone upon completion of the rebase -
could they be explicitly dropped?).  On completion, those abandoned
commits could be explicitly marked as having been removed in the various
book-keeping lists and logs (if it was useful and helpful). I think this
is a different conceptual view of the work of the rebase - resolve process.
>
> Best Wishes
>
> Phillip
--
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 [this message]
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
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=60cd00c2-7aba-3d74-11fa-d4443f6cd83e@iee.email \
    --to=philipoakley@iee.email \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=lkml@SDF.ORG \
    --cc=phillip.wood@dunelm.org.uk \
    /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