Re: [PATCH v2 1/6] t1300: make tests more robust with non-default ref backends

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

 



On Tue, Jan 23, 2024 at 02:41:17PM +0100, Toon Claes wrote:
> 
> Patrick Steinhardt <ps@xxxxxx> writes:
> 
> > [[PGP Signed Part:Undecided]]
> > [1. text/plain]
> > The t1300 test suite exercises the git-config(1) tool. To do so we
> > overwrite ".git/config" to contain custom contents. While this is easy
> > enough to do, it may create problems when using a non-default repository
> > format because we also overwrite the repository format version as well
> > as any potential extensions. With the upcoming "reftable" ref backend
> > the result is that we may try to access refs via the "files" backend
> > even though the repository has been initialized with the "reftable"
> > backend.
> >
> > Refactor tests which access the refdb to be more robust by using their
> > own separate repositories, which allows us to be more careful and not
> > discard required extensions.
> >
> > Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
> > ---
> 
> > @@ -2009,11 +2020,11 @@ test_expect_success '--show-origin getting a single key' '
> >  '
> >
> >  test_expect_success 'set up custom config file' '
> > -	CUSTOM_CONFIG_FILE="custom.conf" &&
> > -	cat >"$CUSTOM_CONFIG_FILE" <<-\EOF
> > +	cat >"custom.conf" <<-\EOF &&
> >  	[user]
> >  		custom = true
> >  	EOF
> > +	CUSTOM_CONFIG_FILE="$(test-tool path-utils real_path
> >  custom.conf)"
> >  '
> 
> From the commit message it was not clear to me this change was needed.
> Do you think it's worth it to add something to the commit message
> explaining you now need to copy the custom.conf into each seperate
> repository?

Good point in fact. The problem here is that before, CUSTOM_CONFIG_FILE
was using a relative path that wouldn't be found when cd'ing into the
respective subrepositories. By using `path-utils real_path` we resolve
the relative path to the full path, and thus we can find the file
regardless of our shell's current working directory.

Not sure whether this is worth a reroll, but in case you or others think
that it is then I'm happy to add this explanation.

Patrick

Attachment: signature.asc
Description: PGP signature


[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