From: "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
konglu@minatec.inpg.fr, Lucien Kong <Lucien.Kong@ensimag.imag.fr>,
git@vger.kernel.org,
Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>,
Franck Jonas <Franck.Jonas@ensimag.imag.fr>,
Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>,
Huynh Khoi Nguyen Nguyen
<Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCHv5] rebase [-i --exec | -ix] <CMD>...
Date: Thu, 14 Jun 2012 00:43:06 +0200 [thread overview]
Message-ID: <4FD9177A.5030303@in.waw.pl> (raw)
In-Reply-To: <7vr4tig7rg.fsf@alter.siamese.dyndns.org>
On 06/14/2012 12:35 AM, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
>
>> Not so fast.
>>
>> exec cmd1 && cmd2
>> and
>> exec cmd1
>> exec cmd2
>>
>> are far from equivalent: If cmd1 fails, the first version never runs
>> cmd2, but the second version runs cmd2 upon rebase --continue.
>
> This reminds me of one thing.
>
> For "exec" insns that are meant to validate each commit in the
> resulting history, what should happen (I am not asking what the
> current implementation of "rebase -i" does) after "exec cmd1" fails?
>
> Ideally, the user will at that point fix the problem in the code,
> run "commit --amend" to record the fix, and then want to make sure
> it really fixed it by re-running "exec cmd1", no?
>
> Shouldn't "rebase --continue" after such a "commit --amend" resume
> execution from "exec cmd1", which failed in the initial run?
>
> I said in the beginning 'For "exec" insns that are meant to validate',
> as "exec" is not necessarily about validation, and other use cases
> of it may want it run only once in the sequence, whether it succeeds
> or fails. So perhaps we would need two kinds of "exec", one that
> just runs once and is not re-run even if the initial round fails,
> and another (perhaps spell it "test") that runs upon "--continue"
> until it passes. The latter of course can be skipped by the user
> with "rebase --skip".
A different proposal would be to add a 'rebase --retry' which would
inoke the last command again. And then the advice after 'exec' could say
"Use --retry to rerun this command, and --continue to proceed with the
next one".
--retry could make sense for 'apply' commands too: if a commit fails to
apply, one could do
git reset --hard HEAD^
hack hack adjusting the preimage
git commit
git rebase --retry
Using --retry to rerun tests would have the advantage that one normally
doesn't think that the tests will fail, so could get into the habit of
using 'exec', not 'test', for the verification commands.
Just thinking aloud.
Zbyszek
next prev parent reply other threads:[~2012-06-13 22:43 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-04 13:47 [PATCH] rebase [-i --exec | -ix] <CMD> Kong Lucien
2012-06-04 17:42 ` Junio C Hamano
2012-06-04 20:30 ` Matthieu Moy
2012-06-04 21:06 ` Junio C Hamano
2012-06-05 17:59 ` konglu
2012-06-05 18:13 ` Junio C Hamano
2012-06-04 17:48 ` Matthieu Moy
2012-06-06 10:34 ` [PATCHv2] " Lucien Kong
2012-06-06 20:03 ` Matthieu Moy
2012-06-06 22:54 ` Junio C Hamano
2012-06-07 8:25 ` Zbigniew Jędrzejewski-Szmek
2012-06-07 8:40 ` Johannes Sixt
2012-06-07 12:04 ` konglu
2012-06-07 13:43 ` Matthieu Moy
2012-06-08 14:53 ` [PATCHv3 1/2] git-rebase.txt: "--onto" option updated Lucien Kong
2012-06-08 14:53 ` [PATCHv3 2/2] rebase [-i --exec | -ix] <CMD> Lucien Kong
2012-06-08 17:02 ` Johannes Sixt
2012-06-08 18:56 ` Torsten Bögershausen
2012-06-08 19:15 ` konglu
2012-06-08 19:55 ` Torsten Bögershausen
2012-06-08 20:07 ` konglu
2012-06-08 20:51 ` Torsten Bögershausen
2012-06-08 21:03 ` konglu
2012-06-09 6:14 ` Torsten Bögershausen
2012-06-09 6:47 ` konglu
2012-06-10 10:44 ` [PATCHv4] " Lucien Kong
2012-06-10 11:56 ` Johannes Sixt
2012-06-11 15:14 ` Junio C Hamano
2012-06-12 18:55 ` Johannes Sixt
2012-06-12 20:29 ` Junio C Hamano
2012-06-12 8:05 ` [PATCHv5] " Lucien Kong
2012-06-12 9:23 ` Zbigniew Jędrzejewski-Szmek
2012-06-12 14:46 ` Junio C Hamano
2012-06-13 14:04 ` Zbigniew Jędrzejewski-Szmek
2012-06-13 17:32 ` Junio C Hamano
2012-06-13 18:05 ` konglu
2012-06-13 18:22 ` Junio C Hamano
2012-06-13 19:38 ` konglu
2012-06-13 20:59 ` Johannes Sixt
2012-06-13 21:07 ` Zbigniew Jędrzejewski-Szmek
2012-06-13 22:25 ` Junio C Hamano
2012-06-13 22:35 ` Junio C Hamano
2012-06-13 22:43 ` Zbigniew Jędrzejewski-Szmek [this message]
2012-06-14 6:57 ` Matthieu Moy
2012-06-14 14:08 ` Marc Branchaud
2012-06-08 15:00 ` [PATCHv3 1/2] git-rebase.txt: "--onto" option updated Matthieu Moy
2012-06-08 17:07 ` Junio C Hamano
2012-06-08 19:06 ` konglu
2012-06-08 19:52 ` Junio C Hamano
2012-06-08 20:08 ` konglu
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=4FD9177A.5030303@in.waw.pl \
--to=zbyszek@in.waw.pl \
--cc=Franck.Jonas@ensimag.imag.fr \
--cc=Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr \
--cc=Lucien.Kong@ensimag.imag.fr \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=Thomas.Nguy@ensimag.imag.fr \
--cc=Valentin.Duperray@ensimag.imag.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=konglu@minatec.inpg.fr \
/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 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 NNTP newsgroup(s).