From: Jason Gunthorpe <jgg@nvidia.com>
To: Konstantin Ryabitsev <mricon@kernel.org>
Cc: tools@kernel.org
Subject: Re: b4 defered branch checkout
Date: Tue, 25 Aug 2026 18:13:15 -0300 [thread overview]
Message-ID: <20260825211315.GH3325090@nvidia.com> (raw)
In-Reply-To: <20260825-uncovered-cerise-rabbit-0064df@meerkat>
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
prev parent reply other threads:[~2026-08-25 21:13 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
2026-08-25 21:13 ` Jason Gunthorpe [this message]
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=20260825211315.GH3325090@nvidia.com \
--to=jgg@nvidia.com \
--cc=mricon@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox