Re: [BUG REPORT] `git rebase --exec` shouldn't run the exec command when there is nothing to rebase

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Nov 26 2021, Nikita Bobko wrote:

> Steps:
> git rebase HEAD --exec "echo foo"
>
> EXPECTED: since 0 commits are going to be rebased then I expect "foo"
> NOT to be printed
> ACTUAL:   "foo" is printed

I don't think this is a bug, but explicitly desired behavior. When you
do:

    git rebase -x 'make test' BASE

You expect to run 'make test' for all of BASE..HEAD inclusive of
"base". E.g. for HEAD~1 we'll run 'make test' twice, and you know both
your HEAD~ and HEAD passed tests.

So why wouldn't doing the same for HEAD make sense?

That being said perhaps some users would think an option or
configuration to skip the injection of "exec" after "noop" would make
sense in that case.

But does this really have anything per-se to do with --exec? Wouldn't
such an option/configuration be the same as rebase in general dying if
there's no work to do?

And wouldn't such a thing be more useful than a narrow change to make
--exec a NOOP in these cases?

E.g. if I've got a "topic" that has commit "A", that's since been
integrated into my upstream and I have a script to "make test" on my
topics, won't simply dying (and thus indicating that the topic is
dead/integrated) be better than noop-ing?