Feature idea: git rebase --exec $CMD

Hi,

I find the x/exec function in "git rebase -i" very useful, but it may be tedious to edit the commit list to add something like "make test" after each commit.

Can this functionality be exposed from the command line as well? I am thinking to a [-x|--exec <command>] options which accepts a command as an argument, and executes such command after each commit in the list of commits which are going to be rebased, and stops the rebasing if the command returns a non-0 value.

Maybe this -x option should conflict with -i to simplify its "execute the command after each commit" semantics (what if it is combined with -i and 'x/exec' lines?).

I can draft the man page section for it, but I doubt I can work on the code for now, so I wanted to throw the idea here and see if anyone else wants to pick it up.

I read that calling a "make test" command after each commit could be done using "git rev-list" like in http://sethrobertson.github.com/GitPostProduction/gpp.html#post-post-production but a more friendly way to do that from CLI would be great.

Thanks,
   Antonio

P.S. I am not subscribed to the list, please CC me.

On Sat, May 5, 2012 at 1:26 PM, Antonio Ospite <ospite@studenti.unina.it> wrote:

FWIW I have had the need for this, I think it's a good idea.

No need for this; this is a sane mailing list that doesn't munge Reply-To, so everybody has to 'reply to all'. To be sure you can add yourself in the CC list, but I think most clients would do the right thing regardless.

Cheers.

[1] http://felipec.wordpress.com/2010/08/03/avoid-reply-to-munging-mail-as-mail-was-meant-to-be/

Antonio Ospite <ospite@studenti.unina.it> writes:

Actually, implementation-wise, it's simpler to have '-x' imply '-i', and suggest a todo-list containing 'x' lines. Then, the code would simply have to add these "x whatever" lines, and let the "git-rebase--interactive.sh" mechanics do the job. That would show the "x whatever" lines to the user, but that can be seen as added value, since it gives an opportunity to the user to remove or edit some of them if needed.

I'm not familiar with the code behind non-interactive rebase, but it doesn't seem to use the same todo-list at all. Maybe the sequencer would help, I don't know.

On Sun, 06 May 2012 12:03:49 +0200 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Thanks Matthieu,

this sounds like a reasonable default behavior for the case of '-x' and '-i' _combined_, but I still think '-x' with no invocation of $EDITOR can have its use case (e.g. a "make validate-commits" calling 'git rebase -x "make test" master').

But I'd like to hear other opinions about that.

Thanks,
   Antonio

On Sun, May 06, 2012 at 12:03:49PM +0200, Matthieu Moy wrote:

Yeah, that makes a lot of sense to me. FWIW, I use this trick now:

  GIT_EDITOR='sed -i "/^pick .*/aexec $test"' \
  git rebase -i "$@"

to test individual commits on a topic before publishing it. But it would be awesome to do:

  git rebase -ix "$test" "$@"

instead (and clean up the quoting disaster waiting to happen in my sed invocation). We should perhaps start slow and call this "--exec" instead of stealing the short-and-sweet "-x" until the feature is more proven, though.

With "-m", it's basically just a for loop over the commits, so I don't know that it would be too hard, but there may be bad interactions. With stock rebase using the "git-rebase--am" backend, it's a bit harder, as we are just bulk-feeding the contents between format-patch and am.

However, I like that the "-i" case already has a concept of execute-and-stop-if-fail, and that we can just build on that. I hope one day that it will all be unified via the sequencer code, but for now, it's not. Having the option mean "just add some exec lines to the todo file" is very simple and not likely to cause bugs.

As tempting as it would be to have "-x" imply "-i", I think it makes sense for it to simply fail in the non-interactive case (and say "sorry, not supported yet"). Then people can experiment with making it work for the non-interactive case (or when the non-interactive case eventually just uses the same code without the editor invocation), we won't be trapped into always having "-x" start the editor.

-Peff

Antonio Ospite <ospite@studenti.unina.it> writes:

I've added this idea here:

  https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_-i_--exec_CMD

maybe I'll get on of my students to code it soon :-).

Antonio Ospite <ospite@studenti.unina.it> writes:

I've taken a more general approach inspired by run-command-on-git-revisions at https://github.com/garybernhardt/dotfiles/tree/master/bin

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.

I think that's a more flexible approach than tying it to rebase.

Thoughts?

                          -Dave

<dag@cray.com> writes:

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.
  At that point, you probably want to rebase against upstream too, to
  make sure you're developping against the latest revision, before
  sening a patch serie or pushing.

* 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".

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.

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Yep, I have done that many times using the above-mentioned script (obviously not during rebase).

That's a good point.

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