Hi,
this is the second version of my patch series that addresses tests which
are specific to the "files" backend. Changes compared to v1:
- I've rewritten the patch addressing t1300 to not mark tests as
repository format specific anymoreg. Instead, we now create separate
repos for relevant tests where we are more careful to not discard
extensions.
- I've made the casing of config options more consistent.
- I've extended some commit messages to hopefully explain better why
I'm doing things the way I do them and fixed some typos.
Thanks for your feedback!
Patrick
Patrick Steinhardt (6):
t1300: make tests more robust with non-default ref backends
t1301: mark test for `core.sharedRepository` as reffiles specific
t1302: make tests more robust with new extensions
t1419: mark test suite as files-backend specific
t5526: break test submodule differently
t: mark tests regarding git-pack-refs(1) to be backend specific
t/t1300-config.sh | 74 +++++++++++++++++++++++------------
t/t1301-shared-repo.sh | 2 +-
t/t1302-repo-version.sh | 19 +++++++--
t/t1409-avoid-packing-refs.sh | 6 +++
t/t1419-exclude-refs.sh | 6 +++
t/t3210-pack-refs.sh | 6 +++
t/t5526-fetch-submodules.sh | 2 +-
7 files changed, 83 insertions(+), 32 deletions(-)
Range-diff against v1:
1: ec1b5bdd17 < -: ---------- t1300: mark tests to require default repo format
-: ---------- > 1: 0552123fa3 t1300: make tests more robust with non-default ref backends
2: 68e308c200 = 2: 384250fec2 t1301: mark test for `core.sharedRepository` as reffiles specific
3: 9af1e418d4 ! 3: 1284b70fab t1302: make tests more robust with new extensions
@@ t/t1302-repo-version.sh: allow 1 noop-v1
test_expect_success 'precious-objects allowed' '
- mkconfig 1 preciousObjects >.git/config &&
-+ git config core.repositoryformatversion 1 &&
++ git config core.repositoryFormatVersion 1 &&
+ git config extensions.preciousObjects 1 &&
check_allow
'
4: d7c6b8b2a7 ! 4: c6062b612c t1419: mark test suite as files-backend specific
@@ Commit message
excluded pattern(s), 2023-07-10) we have implemented logic to handle
excluded refs more efficiently in the "packed" ref backend. This logic
allows us to skip emitting refs completely which we know to not be of
- any interest to the caller, which can avoid quite some allocaitons and
+ any interest to the caller, which can avoid quite some allocations and
object lookups.
This was wired up via a new `exclude_patterns` parameter passed to the
backend's ref iterator. The backend only needs to handle them on a best
effort basis though, and in fact we only handle it for the "packed-refs"
- file, but not for loose references. Consequentially, all callers must
- still filter emitted refs with those exclude patterns.
+ file, but not for loose references. Consequently, all callers must still
+ filter emitted refs with those exclude patterns.
The result is that handling exclude patterns is completely optional in
the ref backend, and any future backends may or may not implement it.
Let's thus mark the test for t1419 to depend on the REFFILES prereq.
+ An alternative would be to introduce a new prereq that tells us whether
+ the backend under test supports exclude patterns or not. But this does
+ feel a bit overblown:
+
+ - It would either map to the REFFILES prereq, in which case it feels
+ overengineered because the prereq is only ever relevant to t1419.
+
+ - Otherwise, it could auto-detect whether the backend supports exclude
+ patterns. But this could lead to silent failures in case the support
+ for this feature breaks at any point in time.
+
+ It should thus be good enough to just use the REFFILES prereq for now.
+ If future backends ever grow support for exclude patterns we can easily
+ add their respective prereq as another condition for this test suite to
+ execute.
+
Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
## t/t1419-exclude-refs.sh ##
5: 51e494a50e ! 5: ae08afc459 t5526: break test submodule differently
@@ Commit message
delete the `HEAD` reference will stop working.
Adapt the code to instead delete the objects database. Going back with
- this new way to cuase breakage confirms that it triggers the infinite
+ this new way to cause breakage confirms that it triggers the infinite
recursion just the same, and there are no equivalent ongoing efforts to
replace the object database with an alternate backend.
6: a9620f329d = 6: df648be535 t: mark tests regarding git-pack-refs(1) to be backend specific
--
2.43.GIT
Attachment:
signature.asc
Description: PGP signature
