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

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