All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <mricon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: tools@kernel.org
Subject: Re: b4 defered branch checkout
Date: Tue, 25 Aug 2026 16:31:46 -0400	[thread overview]
Message-ID: <20260825-uncovered-cerise-rabbit-0064df@meerkat> (raw)
In-Reply-To: <20260824164031.GQ244917@nvidia.com>

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

  reply	other threads:[~2026-08-25 20:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 16:40 b4 defered branch checkout Jason Gunthorpe
2026-08-25 20:31 ` Konstantin Ryabitsev [this message]
2026-08-25 21:13   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260825-uncovered-cerise-rabbit-0064df@meerkat \
    --to=mricon@kernel.org \
    --cc=jgg@nvidia.com \
    --cc=tools@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.