b4 defered branch checkout

b4 defered branch checkout

[Jason Gunthorpe]

I am looking at commit ad80ce422da0 ("review: defer branch checkout to
shell/agent use") and think the way b4 treats the checkout is
inconsistent.

If you <enter> on a fresh series you get the series review
screen and the worktre is (usually?) left checked out.

If you go back with Q then <enter> again, now it isn't checked out.

The above commit make it seem like no checkout is the preferd design
and the residual checkout on the initial open is a bug?

However, I actually want to have the checkout. I want it *always*
checked out for review. I want to use a parallel editor window to
inspect the applied series in more detail that just reading the diffs,
while continuing to use the tui, I don't want to stop the review
workflow and drop to a shell.

From that angle I view the above as a regression.

Further, if it doesn't get checked out what even was the point in
getting it applied to a branch and fixing the conflicts just to get
into the review screen?

I get that other people may not use a dedicated git tree just to run
the review UI with, but could b4 support two workflow options:
 a) never change the checkout work tree
 b) always set the checkout work tree to the current review

?

Thanks,
Jason

Re: b4 defered branch checkout

[Konstantin Ryabitsev]

On Mon, Aug 24, 2026 at 01:40:31PM -0300, Jason Gunthorpe wrote:
> I am looking at commit ad80ce422da0 ("review: defer branch checkout to
> shell/agent use") and think the way b4 treats the checkout is
> inconsistent.
> 
> If you <enter> on a fresh series you get the series review
> screen and the worktre is (usually?) left checked out.

It's not really intentional -- it's because we've literally just created this
branch, so the tree is on it when we load up the series.

> If you go back with Q then <enter> again, now it isn't checked out.

On "Q" we go back to the branch you were on before, and now when we enter
the review again, the branch is already there and we don't need to create it,
so we don't make any git operations that touch your tree.

> The above commit make it seem like no checkout is the preferd design
> and the residual checkout on the initial open is a bug?

Kinda, yes -- the main goal was to remove latency on entering review mode,
because on large trees switching branches can be an intensive process.

> However, I actually want to have the checkout. I want it *always*
> checked out for review. I want to use a parallel editor window to
> inspect the applied series in more detail that just reading the diffs,
> while continuing to use the tui, I don't want to stop the review
> workflow and drop to a shell.

Noted. The question is, how to make this the preferred operation for you while
keeping churn minimal for someone who doesn't actually want their branches
switched every time they enter a series. My immediate thought is to bind this
to two different keys -- a regular "enter" would preserve the current light
no-switch behaviour, while Ctrl-Enter would check out the branch for you.
Would that be an option?

> From that angle I view the above as a regression.
> 
> Further, if it doesn't get checked out what even was the point in
> getting it applied to a branch and fixing the conflicts just to get
> into the review screen?

Well, there are many reasons, but the primary consideration for me was to
speed up the operation and perform the switch when we actually want to work on
the branch (drop to shell, run an agent, etc).

Let me know if the enter vs ctrl-enter logic would be sufficient, or if this
needs to be settable via configuration.

-K

Re: b4 defered branch checkout

[Jason Gunthorpe]

On Tue, Aug 25, 2026 at 04:31:46PM -0400, Konstantin Ryabitsev wrote:
> On Mon, Aug 24, 2026 at 01:40:31PM -0300, Jason Gunthorpe wrote:
> > I am looking at commit ad80ce422da0 ("review: defer branch checkout to
> > shell/agent use") and think the way b4 treats the checkout is
> > inconsistent.
> > 
> > If you <enter> on a fresh series you get the series review
> > screen and the worktre is (usually?) left checked out.
> 
> It's not really intentional -- it's because we've literally just created this
> branch, so the tree is on it when we load up the series.

I thought that was done in some temporary dir though? The am
resolution was in temp dirs I thought?

> > However, I actually want to have the checkout. I want it *always*
> > checked out for review. I want to use a parallel editor window to
> > inspect the applied series in more detail that just reading the diffs,
> > while continuing to use the tui, I don't want to stop the review
> > workflow and drop to a shell.
> 
> Noted. The question is, how to make this the preferred operation for you while
> keeping churn minimal for someone who doesn't actually want their branches
> switched every time they enter a series. My immediate thought is to bind this
> to two different keys -- a regular "enter" would preserve the current light
> no-switch behaviour, while Ctrl-Enter would check out the branch for you.
> Would that be an option?

Well, I would rather have it be the default on enter.. Could there be
some easy way to make the keymap configurable? I see it has named
commands internally, so maybe that is not too big of a thing to ask
for? ie in this case I could bind enter to cmd-review-with-checkout
and you can default bind that to ctrl-enter

I have a feeling such a general functionality would help with
different workflows down the road too.

> > Further, if it doesn't get checked out what even was the point in
> > getting it applied to a branch and fixing the conflicts just to get
> > into the review screen?
> 
> Well, there are many reasons, but the primary consideration for me was to
> speed up the operation and perform the switch when we actually want to work on
> the branch (drop to shell, run an agent, etc).

I like having the branch, but I hate being forced to make the branch.

There are a pile of series in my review queue where I just cannot make
branches for them without a lot of effort. So, I can't use the series
review tui on them which defeats the purpose of using b4 review...

Yet, I don't need the branch to do most of the operations in the
review flow, right?

For b4, it would be nice to be able to not have the branch and still
use the review tui, somehow..

I would really love greater standardization on how to present a series
so it can be applied. Both for this and for sashiko.dev, but that may
be too much to hope for. Many things have git locations in the cover
letter, fetching them would help a lot.

Thanks,
Jason