All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood@talktalk.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	phillip.wood@dunelm.org.uk
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Stefan Beller <sbeller@google.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 2/2] rebase -i: introduce the 'break' command
Date: Fri, 12 Oct 2018 12:09:50 +0100	[thread overview]
Message-ID: <3e2f9343-8b01-c6e5-9425-1665920cc920@talktalk.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1810121035190.45@tvgsbejvaqbjf.bet>

Hi Johannes
On 12/10/2018 09:35, Johannes Schindelin wrote:
> Hi Phillip,
> 
> On Thu, 11 Oct 2018, Phillip Wood wrote:
> 
>> I think this would be a useful addition to rebase, there's one small
>> comment below.
>>
>> On 10/10/2018 09:53, Johannes Schindelin via GitGitGadget wrote:
>>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>>>
>>> The 'edit' command can be used to cherry-pick a commit and then
>>> immediately drop out of the interactive rebase, with exit code 0, to let
>>> the user amend the commit, or test it, or look around.
>>>
>>> Sometimes this functionality would come in handy *without*
>>> cherry-picking a commit, e.g. to interrupt the interactive rebase even
>>> before cherry-picking a commit, or immediately after an 'exec' or a
>>> 'merge'.
>>>
>>> This commit introduces that functionality, as the spanking new 'break'
>>> command.
>>>
>>> Suggested-by: Stefan Beller <sbeller@google.com>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>> ---

>>> diff --git a/sequencer.c b/sequencer.c
>>> index 8dd6db5a01..b209f8af46 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c

>>> @@ -3293,6 +3295,9 @@ static int pick_commits(struct todo_list *todo_list, struct replay_opts *opts)
>>>  			unlink(rebase_path_stopped_sha());
>>>  			unlink(rebase_path_amend());
>>>  			delete_ref(NULL, "REBASE_HEAD", NULL, REF_NO_DEREF);
>>> +
>>> +			if (item->command == TODO_BREAK)
>>> +				break;
>>
>> Normally when rebase stops it prints a message to say where it has got
>> to and how to continue, it might be useful to do the same here
> 
> That's a very valid point. I'll think of something.

I'm not sure what gets left on the screen from the previous picks but
something to say what the last pick/exec was and maybe what the current
HEAD is would be useful I think. One thing has just occurred to me -
what does git status say (and does it still work - I'm not sure how much
parsing it does on the todo and done files) if it is run while rebase is
stopped on a break command?

Best Wishes

Phillip

  reply	other threads:[~2018-10-12 11:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 15:00 [PATCH 0/1] rebase -i: introduce the 'break' command Johannes Schindelin via GitGitGadget
2018-10-03 15:00 ` [PATCH 1/1] " Johannes Schindelin via GitGitGadget
2018-10-05  8:15   ` Junio C Hamano
2018-10-05  8:36     ` Jacob Keller
2018-10-05 15:36     ` Johannes Schindelin
2018-10-09  3:59       ` Junio C Hamano
2018-10-09  5:27         ` Junio C Hamano
2018-10-10  8:53 ` [PATCH v2 0/2] " Johannes Schindelin via GitGitGadget
2018-10-10  8:53   ` [PATCH v2 1/2] rebase -i: clarify what happens on a failed `exec` Johannes Schindelin via GitGitGadget
2018-10-10  9:46     ` Eric Sunshine
2018-10-11  8:15       ` Junio C Hamano
2018-10-12  8:36         ` Johannes Schindelin
2018-10-10  8:53   ` [PATCH v2 2/2] rebase -i: introduce the 'break' command Johannes Schindelin via GitGitGadget
2018-10-11  9:08     ` Phillip Wood
2018-10-12  8:35       ` Johannes Schindelin
2018-10-12 11:09         ` Phillip Wood [this message]
2018-10-12 11:24           ` Johannes Schindelin
2018-10-12 13:14   ` [PATCH v3 0/2] " Johannes Schindelin via GitGitGadget
2018-10-12 13:14     ` [PATCH v3 1/2] rebase -i: clarify what happens on a failed `exec` Johannes Schindelin via GitGitGadget
2018-10-12 13:14     ` [PATCH v3 2/2] rebase -i: introduce the 'break' command Johannes Schindelin via GitGitGadget
2018-10-12 14:09       ` Junio C Hamano
2018-10-12 15:31         ` Johannes Schindelin
2018-10-12 14:01     ` [PATCH v3 0/2] " Junio C Hamano
2018-10-12 15:32       ` Johannes Schindelin
2018-10-25 20:47     ` [PATCH 3/2] rebase -i: recognize short commands without arguments Johannes Sixt
2018-10-26  1:26       ` Junio C Hamano
2018-10-26  8:04       ` 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=3e2f9343-8b01-c6e5-9425-1665920cc920@talktalk.net \
    --to=phillip.wood@talktalk.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sbeller@google.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.