Re: [PATCH v5 5/5] branch: do not mark the branch the current worktree is rebasing

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

Jasper Mayone <me@jaspermayone.com> writes:

> Since "ref-filter: name the worktree of a branch being rebased or
> bisected", "git branch" marks a branch with "+" when a worktree is

It cannot be avoided but it is awkward that we have to refer to a
commit without a carved-into-stone object name yet.  I wonder if

    Since "ref-filter: name ..." that is a few commits ago in this
    series, ...

or something along that line would help?

> rebasing or bisecting it. In that worktree itself, the list already
> starts with "* (no branch, rebasing topic)", so a "+ topic" line
> below it shows the same branch twice.

Two comments.

 - in what context the command "marks a branch" is unclear.  Are you
   talking about "git branch --list" output?

 - does this talk about a regression in the middle of a series?  Can
   we avoid such a regression by reordering commits in some way?

I seem to have ~600-700 local branches in the repository I usually
work in (with a handful of worktrees), and I do see the list starts
with

  * (no branch, bisect started on jm/worktree-rebase-bisect-checked-out)
  ab/describe-no-i18n-of-debug-messages
  ab/index-pack-retain-child-bases
  ...

but by the time I scroll down to see the branches around it, I suspect

  ...
  jk/test-lazy-prereq-heredoc
  jk/unit-tests-via-test-lib
  jk/xdiff-size_t
  jm/t0213-skip-emulated-ancestry-tests
  jm/worktree-rebase-bisect-checked-out
  jr/bisect-custom-terms-in-output
  js/adjust-tests-to-explicitly-access-bare-repo
  ...

that I would appreciate the branch currently being bisected marked
as such in the list, together with any other branches being bisected
in other worktrees.

So, unless I am missing a use case this change is trying to cater
to, I am a bit negative on this change.  If the [4/5] were solely to
support this step, then stopping the series at [3/5] might be
sufficient.

Thanks.