On Thu, Aug 5, 2010 at 13:00, Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote:
> The typical usage pattern would be to run a test (or simply a compilation
> command) at given points in history.
>
> The shell command is ran (from the worktree root), and the rebase is
> stopped when the command fails, to give the user an opportunity to fix
> the problem before continuing with "git rebase --continue".
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@xxxxxxx>
> ---
>
> So, back to the "run from tree root", but that't now properly
> documented and tested.
>
> One notable difference with my first version is that the command is
> ran in a subshell, defaulting to $SHELL (typically for users like me
> with $SHELL=zsh who may want to take advantage of their shell's
> advanced features)
>
> Documentation/git-rebase.txt | 24 +++++++++++++++++++
> git-rebase--interactive.sh | 20 ++++++++++++++++
> t/lib-rebase.sh | 2 +
> t/t3404-rebase-interactive.sh | 50 +++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 96 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index be23ad2..4bd4b66 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -459,6 +459,30 @@ sure that the current HEAD is "B", and call
> $ git rebase -i -p --onto Q O
> -----------------------------
>
> +Reordering and editing commits usually creates untested intermediate
> +steps. You may want to check that your history editing did not break
> +anything by running a test, or at least recompiling at intermediate
> +points in history by using the "exec" command (shortcut "x"). You may
> +do so by creating a todo list like this one:
> +
> +-------------------------------------------
> +pick deadbee Implement feature XXX
> +fixup f1a5c00 Fix to feature XXX
> +exec make
> +pick c0ffeee The oneline of the next commit
> +edit deadbab The oneline of the commit after
> +exec cd subdir; make test
> +...
> +-------------------------------------------
> +
> +The interactive rebase will stop when a command fails (i.e. exits with
> +non-0 status) to give you an opportunity to fix the problem. You can
> +continue with `git rebase --continue`.
> +
> +The "exec" command launches the command in a shell (the one specified
> +in `$SHELL`, or the default shell if `$SHELL` is not set), so you can
> +use usual shell commands like "cd". The command is run from the
I think that needs a definite article: ".. use the usual ..".
> +# debugging-friendly alternatives to "test -f" and "test ! -f"
> +file_must_exist () {
> + if ! [ -f "$1" ]; then
> + echo "file $1 not created."
> + false
> + fi
> +}
> +
> +file_must_not_exist () {
> + if [ -f "$1" ]; then
> + echo "file $1 created while it shouldn't have. $2"
> + false
> + fi
> +}
As I pointed out in a previous comment to the series this sort of
debug code should either be converted to use "test" or we should
incorporate it into test-lib.sh and use it everywhere.
I somewhat like the latter. It's sometimes hard to see what's going
wrong with our tests. It'd also translate to TAP subtests.
Otherwise this all looks good. Especially without the fragile mkdir/chdir
part present in a previous submission.
--
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