Re: includeIf not matching during `git rebase`

[Junio C Hamano <gitster@pobox.com>]

Emily Shaffer <nasamuffin@google.com> writes:

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

Not really.  The low-level config machinery shouldn't rely on a
piece of information from so high a layer (making call to
wt_status.c or spawning "git status" is an absolute no-no).

But "we are not exactly on branch X, but doing work on behalf of
branch X" is a common situation during rebase and possibly bisect,
and I agree that it is a good future direction to introduce a
reliable low-level primitive to notice that condition.

I however am hesitant to fully support such an idea, because I
suspect that there may be cases such as "we are technically on
branch Y, but actually doing work on behalf of branch X" or worse
yet "we are on branch Z, but actually doing work on behalf of both
branches X and Y", where there are more than one plausible branch,
which is different from what HEAD points at, that
include_by_branch() could use.

Thanks.