git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

             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).