aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorHan-Wen Nienhuys <hanwen@google.com>2019-10-13 18:14:17 +0200
committerMatthias Sohn <matthias.sohn@sap.com>2019-10-30 18:00:24 +0100
commit7c75a68b9635848a8231df8a1461c3f9405a55f4 (patch)
treee9b54091ddf135b501b713e839c62c00ebe808f2 /Documentation
parentcf11a03bc267fa86aa5dc538ff0ffc777d659c8a (diff)
downloadjgit-7c75a68b9635848a8231df8a1461c3f9405a55f4.tar.gz
jgit-7c75a68b9635848a8231df8a1461c3f9405a55f4.zip
reftable: enforce ascending order in sortAndWriteRefs
MergedReftableTest#scanDuplicates tests whether we can write duplicate keys in a merged reftable. Apparently, the first key appearing should get precedence, and this works because the sort() algorithm on ordered collections is stable. This is potentially confusing behavior, because you can write data into the table that cannot be retrieved (Merged table can only have one entry per key), and the APIs such as exactRef() only return a single value. Make this consistent with behavior introduced in I04f55c481 "reftable: enforce ordering for ref and log writes" by considering a duplicate key in sortAndWriteRefs as a fatal runtime error. Change-Id: I1eedd18f028180069f78c5c467169dcfe1521157 Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/technical/reftable.md4
1 files changed, 4 insertions, 0 deletions
diff --git a/Documentation/technical/reftable.md b/Documentation/technical/reftable.md
index 9e5c521fca..1236a79098 100644
--- a/Documentation/technical/reftable.md
+++ b/Documentation/technical/reftable.md
@@ -89,6 +89,10 @@ Reference names are an uninterpreted sequence of bytes that must pass
[ref-fmt]: https://git-scm.com/docs/git-check-ref-format
+### Key unicity
+
+Each entry must have a unique key; repeated keys are disallowed.
+
### Network byte order
All multi-byte, fixed width fields are in network byte order.