rebase: offer to reschedule failed exec commands automatically
#90
Conversation
cc1834a to
86ed094
Compare
|
/submit |
|
An error occurred while submitting: Error: git fetch https://github.com/gitgitgadget/git -- +refs/notes/gitgitgadget:refs/notes/gitgitgadget +refs/pull/90/head:refs/pull/90/head +refs/heads/maint:refs/remotes/upstream/maint +refs/heads/master:refs/remotes/upstream/master +refs/heads/next:refs/remotes/upstream/next +refs/heads/pu:refs/remotes/upstream/pu failed: 1,
|
|
/submit |
|
Submitted as pull.90.git.gitgitgadget@gmail.com |
A common use case for the `--exec` option is to verify that each commit in a topic branch compiles cleanly, via `git rebase -x make <base>`. However, when an `exec` in such a rebase fails, it is not re-scheduled, which in this instance is not particularly helpful. Let's offer a flag to reschedule failed `exec` commands. Based on an idea by Paul Morelle. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It would be cumbersome to type out that option all the time, so let's offer the convenience of a config setting: rebase.rescheduleFailedExec. Besides, this opens the door to changing the default in a future version of Git: it does make some sense to reschedule failed `exec` commands by default (and if we could go back in time when the `exec` command was invented, we probably would change that default right from the start). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is a bit cumbersome to write out the `--reschedule-failed-exec` option before `-x <cmd>` all the time; let's introduce a convenient option to do both at the same time: `-y <cmd>`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
86ed094 to
6460b09
Compare
|
This branch is now known as |
|
This patch series was integrated into pu via git@7d3921b. |
|
This patch series was integrated into pu via git@c325fa8. |
|
This patch series was integrated into pu via git@809f8a4. |
|
This patch series was integrated into pu via git@a111575. |
|
This patch series was integrated into pu via git@429e469. |
|
This patch series was integrated into pu via git@9d2a58e. |
|
This patch series was integrated into pu via git@8076fda. |
|
This patch series was integrated into pu via git@987009a. |
|
This patch series was integrated into pu via git@9cae067. |
|
This patch series was integrated into pu via git@7373c51. |
|
This patch series was integrated into pu via git@b5b3ef6. |
|
This patch series was integrated into next via git@71be3fe. |
|
This patch series was integrated into pu via git@d9d9ab0. |
|
This patch series was integrated into next via git@d9d9ab0. |
|
This patch series was integrated into master via git@d9d9ab0. |
|
Closed via d9d9ab0. |
The idea was brought up by Paul Morelle.
To be honest, this idea of rescheduling a failed
execmakes 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.
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.Changes since v1:
--reschedule-failed-execneeds interactive backend" check also in the legacy rebase.