Re: b4 bugs / future improvements

[Maxime Ripard <maxime@cerno.tech>]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

On Tue, Oct 18, 2022 at 04:37:49PM -0400, Konstantin Ryabitsev wrote:
> On Tue, Oct 18, 2022 at 09:29:44PM +0100, Mark Brown wrote:
> > > >    - It's a bit tedious to do. One needs to rebase and then edit the
> > > >      cover letter by hand without b4 being involved. I don't think doing
> > > >      the rebase interface all over again is reasonable, but maybe we
> > > >      could add a subcommand to set a new base?
> > 
> > > Interesting. I'm not sure I fully understand the problem, but then all my
> > > rebase tests were all very simple cases of running "git rebase <newtag>"
> > 
> > > Is there a reason why you have to manually edit the cover letter after a
> > > rebase?
> > 
> > If you're doing an inter-version changelog it's common to say something
> > like "rebased against foo" in there.  It's a bit clearer about things
> > than base-commit.
> 
> No, I don't think that's what Maxime means -- "rebased against foo" can be
> done using "b4 prep --edit-cover".

Yeah, I'm manually editing the JSON part. But tbf, I don't really know
why I started doing it, so it might be fixed for a while, or never an
issue in the first place.

> I think there's two things going on:
> 
> 1. he's using a different cover strategy that requires base-branch tracking
> 2. he's rebasing on a different branch, as opposed to a newer tag within the
>    same branch

If it causes any issue, then it could be the reason yeah. I do rebase
across different branches from time to time, so it might be why I
started doing so.

> That would indeed be as cumbersome as described (and why I'm using the "cover
> letter as an empty commit at the start of the series" strategy as the
> default).
> 
> Maxime, is that correct? I assume you're using "tip-commit"?

I'm using the commit strategy

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]