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?
