From: Elijah Newren <newren@gmail.com>
To: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>
Cc: <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 0/3] rebase: offer to reschedule failed exec commands automatically
Date: Mon, 10 Dec 2018 15:13:11 -0800 [thread overview]
Message-ID: <20181210231311.15621-1-newren@gmail.com> (raw)
In-Reply-To: pull.90.git.gitgitgadget@gmail.com
On Mon, Dec 10, 2018 at 1:18 PM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> The idea was brought up by Paul Morelle.
>
> To be honest, this idea of rescheduling a failed exec makes so much sense
> that I wish we had done this from the get-go.
>
> So let's do the next best thing: implement a command-line option and a
> config setting to make it so.
I was a bit worried that the optics weren't good enough for recovering from
a typoed exec command (or one that otherwise wouldn't be in a state the
user could make pass but they wanted the rebase to continue). However,
after trying it out, I found:
$ git rebase --exec /bin/false --reschedule-failed-exec HEAD~1
Executing: /bin/false
warning: execution failed: /bin/false
You can fix the problem, and then run
git rebase --continue
hint: Could not execute the todo command
hint:
hint: exec /bin/false
hint:
hint: It has been rescheduled; To edit the command before continuing, please
hint: edit the todo list first:
hint:
hint: git rebase --edit-todo
hint: git rebase --continue
and if the user just runs "git rebase --continue" without looking at that big
hint, they'll get the hint again. When they run "git rebase --edit-todo", they
see the failed command listed first and can remove that line.
So, I think my initial worry was unfounded.
> The obvious intent behind that config setting is to not only give users a
> way to opt into that behavior already, but also to make it possible to flip
> the default at a later date, after the feature has been battle-tested and
> after deprecating the non-rescheduling behavior for a couple of Git
> versions.
>
> If the team agrees with my reasoning, then the 3rd patch (introducing -y
> <cmd> as a shortcut for --reschedule-failed-exec -x <cmd>) might not make
> much sense, as it would introduce a short option that would become obsolete
> soon.
This series is awesome; thanks much to Paul for suggesting this idea.
And yeah, I agree and hope the third patch won't be necessary. :-)
> Johannes Schindelin (3):
> rebase: introduce --reschedule-failed-exec
> rebase: add a config option to default to --reschedule-failed-exec
> rebase: introduce a shortcut for --reschedule-failed-exec
>
> Documentation/config/rebase.txt | 5 ++++
> Documentation/git-rebase.txt | 11 +++++++++
> builtin/rebase--interactive.c | 2 ++
> builtin/rebase.c | 42 ++++++++++++++++++++++++++++++++-
> git-legacy-rebase.sh | 24 ++++++++++++++++++-
> git-rebase--common.sh | 1 +
> sequencer.c | 13 +++++++---
> sequencer.h | 1 +
> t/t3418-rebase-continue.sh | 14 +++++++++++
> 9 files changed, 108 insertions(+), 5 deletions(-)
>
>
> base-commit: a1598010f775d82b5adf12c29d0f5bc9b41434c6
> Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-90%2Fdscho%2Freschedule-failed-exec-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-90/dscho/reschedule-failed-exec-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/90
> --
> gitgitgadget
next reply other threads:[~2018-12-10 23:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 23:13 Elijah Newren [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-12-10 19:04 [PATCH 0/3] rebase: offer to reschedule failed exec commands automatically Johannes Schindelin via GitGitGadget
2018-12-10 22:08 ` Johannes Sixt
2018-12-10 22:56 ` Stefan Beller
2018-12-11 3:28 ` Junio C Hamano
2018-12-11 10:31 ` Johannes Schindelin
2018-12-11 17:36 ` Stefan Beller
2018-12-10 23:20 ` Elijah Newren
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=20181210231311.15621-1-newren@gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
/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).