Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()

Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()

[Konstantin Ryabitsev]

On Wed, Jul 12, 2023 at 06:31:29PM +0300, Andy Shevchenko wrote:
> +Cc: Konstantin.
> 
> Konstantin, seems b4 doesn't handle long Subject lines for merge commits
> (PR mode).

Could you give me something more to go on? Was this done with "b4 shazam" or
via some other way?

-K

Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()

[Mark Brown]

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

On Wed, Jul 12, 2023 at 02:09:39PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Jul 12, 2023 at 06:31:29PM +0300, Andy Shevchenko wrote:

> > Konstantin, seems b4 doesn't handle long Subject lines for merge commits
> > (PR mode).

> Could you give me something more to go on? Was this done with "b4 shazam" or
> via some other way?

The patches are applied from mailboxes fetched with b4 am, then the
thanks mails go out with b4 ty.

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

Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()

[Konstantin Ryabitsev]

On Wed, Jul 12, 2023 at 07:35:45PM +0100, Mark Brown wrote:
> > Could you give me something more to go on? Was this done with "b4 shazam" or
> > via some other way?
> 
> The patches are applied from mailboxes fetched with b4 am, then the
> thanks mails go out with b4 ty.

But I think the complaint was about the merge commits being cut off:

    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=5a043fd5c74c66897ad113e5ee34e9361e3f4c11

When I try "b4 shazam -M", the merge commit looks different to me, so I want
to understand how the merge commit is generated in your workflow.

-K

Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()

[Mark Brown]

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

On Wed, Jul 12, 2023 at 02:47:34PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Jul 12, 2023 at 07:35:45PM +0100, Mark Brown wrote:

> > The patches are applied from mailboxes fetched with b4 am, then the
> > thanks mails go out with b4 ty.

> But I think the complaint was about the merge commits being cut off:
> 
>     https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=5a043fd5c74c66897ad113e5ee34e9361e3f4c11

Oh, I see.  The commit in the mail looked like it might be off and it
was in reply to the applied mail so I thought that was what was being
referenced.

> When I try "b4 shazam -M", the merge commit looks different to me, so I want
> to understand how the merge commit is generated in your workflow.

That's generated by my scripts based on the .cover that b4 writes out
and some sed at the point where a merge is done.  There's a bunch of CI
happens between applying the patches and me actually merging them so I
don't use b4 for that bit.  It's just picking the subject line out with
sed so there's no way it's going to handle multi-line subjects.

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

Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()

[Konstantin Ryabitsev]

On Wed, Jul 12, 2023 at 07:59:24PM +0100, Mark Brown wrote:
> > But I think the complaint was about the merge commits being cut off:
> > 
> >     https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=5a043fd5c74c66897ad113e5ee34e9361e3f4c11
> 
> Oh, I see.  The commit in the mail looked like it might be off and it
> was in reply to the applied mail so I thought that was what was being
> referenced.
> 
> > When I try "b4 shazam -M", the merge commit looks different to me, so I want
> > to understand how the merge commit is generated in your workflow.
> 
> That's generated by my scripts based on the .cover that b4 writes out
> and some sed at the point where a merge is done.  There's a bunch of CI
> happens between applying the patches and me actually merging them so I
> don't use b4 for that bit.  It's just picking the subject line out with
> sed so there's no way it's going to handle multi-line subjects.

Will it help if b4 optionally writes out a foo.merge file in addition to
foo.cover in the same format as with "b4 shazam"?

-K

Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()

[Mark Brown]

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

On Wed, Jul 12, 2023 at 03:18:15PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Jul 12, 2023 at 07:59:24PM +0100, Mark Brown wrote:

> > That's generated by my scripts based on the .cover that b4 writes out
> > and some sed at the point where a merge is done.  There's a bunch of CI
> > happens between applying the patches and me actually merging them so I
> > don't use b4 for that bit.  It's just picking the subject line out with
> > sed so there's no way it's going to handle multi-line subjects.

> Will it help if b4 optionally writes out a foo.merge file in addition to
> foo.cover in the same format as with "b4 shazam"?

That sounds like it should be good, yes - I can just use that as the
message rather than generating one (not having seen the specific
format).

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