Feature idea: git rebase --exec $CMD

Feature idea: git rebase --exec $CMD

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

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.

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Feature idea: git rebase --exec $CMD

[Felipe Contreras]

On Sat, May 5, 2012 at 1:26 PM, Antonio Ospite <ospite@studenti.unina.it> wrote:
> 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.

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

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

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/

-- 
Felipe Contreras

Re: Feature idea: git rebase --exec $CMD

[Matthieu Moy]

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

> 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?).

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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Feature idea: git rebase --exec $CMD

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

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

> Antonio Ospite <ospite@studenti.unina.it> writes:
> 
> > 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?).
> 
> 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.
>

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Feature idea: git rebase --exec $CMD

[Jeff King]

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

> > 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?).
> 
> 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.

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.

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

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

Re: Feature idea: git rebase --exec $CMD

[Matthieu Moy]

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

> I find the x/exec function in "git rebase -i" very useful, [...]
> Can this functionality be exposed from the command line as well?

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 :-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Feature idea: git rebase --exec $CMD

[dag]

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

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

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

Re: Feature idea: git rebase --exec $CMD

[Matthieu Moy]

<dag@cray.com> writes:

> Antonio Ospite <ospite@studenti.unina.it> writes:
>
>> 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.
>
> 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.

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
http://www-verimag.imag.fr/~moy/

Re: Feature idea: git rebase --exec $CMD

[dag]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> 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