* Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()
[not found] ` <ZK7HUTyKB6hoaBtV@smile.fi.intel.com>
@ 2023-07-12 18:09 ` Konstantin Ryabitsev
2023-07-12 18:35 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Konstantin Ryabitsev @ 2023-07-12 18:09 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Mark Brown, tools
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()
2023-07-12 18:09 ` [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data() Konstantin Ryabitsev
@ 2023-07-12 18:35 ` Mark Brown
2023-07-12 18:47 ` Konstantin Ryabitsev
0 siblings, 1 reply; 6+ messages in thread
From: Mark Brown @ 2023-07-12 18:35 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Andy Shevchenko, tools
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()
2023-07-12 18:35 ` Mark Brown
@ 2023-07-12 18:47 ` Konstantin Ryabitsev
2023-07-12 18:59 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Konstantin Ryabitsev @ 2023-07-12 18:47 UTC (permalink / raw)
To: Mark Brown; +Cc: Andy Shevchenko, tools
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()
2023-07-12 18:47 ` Konstantin Ryabitsev
@ 2023-07-12 18:59 ` Mark Brown
2023-07-12 19:18 ` Konstantin Ryabitsev
0 siblings, 1 reply; 6+ messages in thread
From: Mark Brown @ 2023-07-12 18:59 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Andy Shevchenko, tools
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()
2023-07-12 18:59 ` Mark Brown
@ 2023-07-12 19:18 ` Konstantin Ryabitsev
2023-07-12 20:31 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Konstantin Ryabitsev @ 2023-07-12 19:18 UTC (permalink / raw)
To: Mark Brown; +Cc: Andy Shevchenko, tools
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data()
2023-07-12 19:18 ` Konstantin Ryabitsev
@ 2023-07-12 20:31 ` Mark Brown
0 siblings, 0 replies; 6+ messages in thread
From: Mark Brown @ 2023-07-12 20:31 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Andy Shevchenko, tools
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-07-12 20:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20230630172155.83754-1-andriy.shevchenko@linux.intel.com>
[not found] ` <168916242630.46574.7633971537485557226.b4-ty@kernel.org>
[not found] ` <ZK6xI8l7Vdp35yJG@smile.fi.intel.com>
[not found] ` <d5cac1ef-1d44-4ab7-a933-b381108b1eaa@sirena.org.uk>
[not found] ` <ZK7HUTyKB6hoaBtV@smile.fi.intel.com>
2023-07-12 18:09 ` [PATCH v2 0/4] ASoC: rt5677: Refactor GPIO and use device_get_match_data() Konstantin Ryabitsev
2023-07-12 18:35 ` Mark Brown
2023-07-12 18:47 ` Konstantin Ryabitsev
2023-07-12 18:59 ` Mark Brown
2023-07-12 19:18 ` Konstantin Ryabitsev
2023-07-12 20:31 ` Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox