Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
>> I took that and turned it into a git-run-command subcommand. It will
>> take an arbitrary command and run it on each revision specified by a
>> revlist.
>
> That's sensible too. The nice things with running commands in "git
> rebase" are:
>
> * It's likely to be the place where you want to run some tests. The
> typical use-case is that you have a patch serie whose last revision
> passes tests, and you want to check that intermediate commits also do.
Yep, I have done that many times using the above-mentioned script
(obviously not during rebase).
> * if the "exec" command fails, you're likely to be exactly in the right
> place to fix it: fix the bug, run "git commit --amend", and "git
> rebase --continue".
That's a good point.
> The nice thing with your approach (as I understand it) is that it
> doesn't require rewritting history, and may apply to all commits in
> non-linear history.
Exactly. I think there is room for both. The downside to
git-run-command (besides the name) is that it forcibly checks out
revisions in the current workarea so one has to be careful about
unstaged and/or uncommitted changes. I could change the behavior to
checkout in some /tmp workarea or something.
-Dave
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html