Re: [PATCH] t9101: Refactor test_expect_success format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 01, 2024 at 08:51:11AM +0100, Seyi Chamber wrote:
> On Thu, 31 Oct 2024 at 21:15, Taylor Blau <me@xxxxxxxxxxxx> wrote:
> >
> > On Thu, Oct 31, 2024 at 10:45:53AM +0100, Seyi Kuforiji wrote:
> > > The current script uses an outdated formatting style for
> > > test_expect_success blocks, where each argument is separated by a
> > > backslash and newline. This style can lead to readability issues and
> > > makes it harder to maintain the script.
> > >
> > > The modern style consolidates
> > > the multi-line command arguments into a single quoted block, which
> >
> > Strange line wrapping?
> >
>
> That error probably occurred while I was editing the message. Should I
> edit and send an updated patch?

Please do so, thanks.

> > > improves readability, maintainability, and aligns the code with current
> > > coding standards.
> > >
> > > Signed-off-by: Seyi Kuforiji <kuforiji98@xxxxxxxxx>
> > > ---
> > >  t/t9101-git-svn-props.sh | 48 ++++++++++++++++++++++------------------
> > >  1 file changed, 26 insertions(+), 22 deletions(-)
> >
> > This does not apply cleanly on 'master', so I assume that you wanted it
> > based on sk/t9101-cleanup. That's fine, but please let me know in the
> > future in case it's every less obvious :-).
> >
> > The changes themselves all look quite sensible, though.
> >
> > Thanks,
> > Taylor
>
> Thanks, Taylor for pointing out this issue. I have rebased my change
> onto the latest master branch and resolved the conflicts for future
> updates.

There is no specific need to rebase on top of current 'master' unless
failing to do so will cause the maintainer to see a conflicted state
when applying.

Unless told otherwise, I will apply new rounds of existing patch series
onto top of their original base.

Thanks,
Taylor




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux