Re: includeIf not matching during `git rebase`

From: Emily Shaffer <nasamuffin@google.com>
Date: Jul 25, 2023, 20:28 UTC
Message-ID: <CAJoAoZnuLxyQ7ufUTrK4mBJ_4sQoyPCqJD9eeS8XfquWue1xQA@mail.gmail.com>
In-Reply-To: <CABb0KFF1vqMLa5DLYd_c9sQeZbhkhQ=Q0bE7W41nmMFmNWB4tg@mail.gmail.com>

On Tue, Jul 25, 2023 at 12:49 PM Michał Mirosław <emmir@google.com> wrote:

Show 15 quoted lines

>
> * What did you do before the bug happened? (Steps to reproduce your issue)
>
> With ~/.gitconfig having:
>
> [includeIf "onbranch:pr/"]
>         path = .gitconfig.for-upstream
>
> where the included config changes commit-msg hook,
>
> git checkout pr/zzz # has multiple commits over upstream
> git rebase -i
> > 'edit' first commit
> (modify it)
> git rebase --continue

Hm, I would guess this is why - in the middle of the rebase, the branch ref doesn't move, it's only moved to the new tip when the rebase is completed. However, it seems that we do have some knowledge of which branch we are trying to rebase:

emilyshaffer@podkayne:~/git [libification-style|REBASE 3/4]$ git
branch | head -n1
* (no branch, rebasing libification-style)

It looks like to log that error, we're using a cached branch name (and pick that up from wt_status_get_state and eventually wt_status_check_rebase, which checks .git/rebase-(merge|apply)/head-name).

However, when we check the current branch for includeif.onbranch (config.c:include_by_branch()) we're using resolve_ref_unsafe("HEAD"), which doesn't check the current rebase state the way that the wt_status_* stuff does.

Does that mean that the config machinery should also be using wt_status to determine which branch to use? The use case Michał is describing sounds perfectly reasonable to me - is there reason to think that doing conditional includes during a rebase based on "the branch we were in the middle of rebasing" would negatively impact someone's existing workflow?

 - Emily