* [PATCH] doc: fix a small, old release notes typo
@ 2026-06-14 17:28 D. Ben Knoble
2026-06-14 21:52 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: D. Ben Knoble @ 2026-06-14 17:28 UTC (permalink / raw)
To: git; +Cc: D. Ben Knoble, Elijah Newren
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
---
No harm done if you choose not to keep this, I think. Stumbled upon it when
trying to understand Elijah's message [1] about timestamp_t overflowing in 2106
(I though 32-bit time_t overflowed in 2038, but timestamp_t is something
different… except maybe when it's not? Anyway…)
[1]: <pull.2148.git.1781420271100.gitgitgadget@gmail.com>
Documentation/RelNotes/2.14.0.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/2.14.0.adoc b/Documentation/RelNotes/2.14.0.adoc
index 2711a2529d..182fbe6179 100644
--- a/Documentation/RelNotes/2.14.0.adoc
+++ b/Documentation/RelNotes/2.14.0.adoc
@@ -142,7 +142,7 @@ Performance, Internal Implementation, Development Support etc.
historical use of ulong for timestamp would mean they cannot
represent some timestamp that the platform allows. Invent a
separate and dedicated timestamp_t (so that we can distinguish
- timestamps and a vanilla ulongs, which along is already a good
+ timestamps and a vanilla ulongs, which alone is already a good
move), and then declare uintmax_t is the type to be used as the
timestamp_t.
base-commit: 0c8ab3ebcc76981376809c8fe632d0fe18e93347
--
2.54.0.1136.gdb2ca164c4.dirty
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] doc: fix a small, old release notes typo
2026-06-14 17:28 [PATCH] doc: fix a small, old release notes typo D. Ben Knoble
@ 2026-06-14 21:52 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2026-06-14 21:52 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: git, Elijah Newren
"D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
> Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
> ---
> No harm done if you choose not to keep this, I think. Stumbled upon it when
> trying to understand Elijah's message [1] about timestamp_t overflowing in 2106
> (I though 32-bit time_t overflowed in 2038, but timestamp_t is something
> different… except maybe when it's not? Anyway…)
Unless it fixes a glaring factual error that would harm end-users if
left unfixed, I would not very much be enthused to see fixes to
these ancient documents, quite honestly.
> separate and dedicated timestamp_t (so that we can distinguish
> - timestamps and a vanilla ulongs, which along is already a good
> + timestamps and a vanilla ulongs, which alone is already a good
"timestamps and vanilla ulongs", as both are plural?
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-06-14 21:52 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-14 17:28 [PATCH] doc: fix a small, old release notes typo D. Ben Knoble
2026-06-14 21:52 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox