From: Phillip Wood Date: Tue, 30 Nov 2021 11:09:34 GMT Subject: Re: [BUG REPORT] `git rebase --exec` shouldn't run the exec command when there is nothing to rebase Message-ID: In-Reply-To: <211129.868rx7gnd5.gmgdl@evledraar.gmail.com> On 29/11/2021 12:07, Ævar Arnfjörð Bjarmason wrote: > > 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. I don't think we run 'make test' for base in that case, only after each pick and base is not picked by the rebase. Best Wishes Phillip > 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? >