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

From: Taylor Blau <me@ttaylorr.com>
Date: Nov 30, 2021, 00:43 UTC
Message-ID: <YaVzufpKcC0t+q+L@nand.local>
In-Reply-To: <CABPp-BFRE2=Owf15WzkacNfdNKbkd2n4GZh7HqDokKzeviBWRw@mail.gmail.com>

On Mon, Nov 29, 2021 at 04:14:33PM -0800, Elijah Newren wrote:

Show 26 quoted lines

> On Mon, Nov 29, 2021 at 2:25 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> 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.
>
> My reading of the docs are such that I'd expect the same as Nikita here:
>
>         Append "exec <cmd>" after each line creating a commit in the final
>         history.
>         ...
>         If --autosquash is used, "exec" lines will not be appended for the
>         intermediate commits, and will only appear at the end of each
>         squash/fixup series.
>
> There is no line creating a commit in the final history when you do a
> git rebase -i --exec "echo foo" HEAD (there is only a noop line), so
> there should be no exec line.

Thanks for quoting the docs here. When I ran this myself, I thought that the docs must say something like "after every line" and not further specify "... creating a commit".

But they do, so I agree with the original report from Nikita that

    git rebase -x 'echo foo' HEAD

should be silent in order to be consistent with the docs.

Show 15 quoted lines

> > 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.
>
> This is not true.  Try `git rebase -i --exec HEAD~$N` for various
> values of N>0.  base is not included.
>
> > So why wouldn't doing the same for HEAD make sense?
>
> Indeed; HEAD is weirdly inconsistent and should be brought in line
> with the others.

Yep.

Thanks, Taylor