Jeff King <peff@xxxxxxxx> writes:
> ... However, I would not be at all surprised if people
> use custom readers.
Yes. I would be surprised if nobody did so.
> I think it may be a good policy to stick to the
> simplest machine-readable formats for trailers. Likewise I'd suggest
> using the full sha1-hex for future-proofing in this context.
Yes, or just roll it into prose like we often do. Anybody can spot
many examples from "git log --no-merges" ;-)
commit 173cb08d5b38f423b3cae409daa6d414348c3459
Author: Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx>
Date: Wed May 20 10:08:43 2020 -0700
bisect: avoid tailing CR characters from revision in replay
6c722cbe5a (bisect: allow CRLF line endings in "git bisect replay"
input, 2020-05-07) includes CR as a field separator, but relies on
it not being included in the last field, which breaks at least when
running under OpenBSD 6.7's sh.
Instead of just assume the CR will get swallowed, read the rest of
the line into an otherwise unused variable and ignore it everywhere
except on the call for git bisect start, where it matters.
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
commit e68a5272b1aab46514ae01745be50948ac375146
Author: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
Date: Tue May 19 19:48:45 2020 +0000
fsck: use ERROR_MULTI_PACK_INDEX
The multi-pack-index was added to the data verified by git-fsck in
ea5ae6c3 "fsck: verify multi-pack-index". This implementation was
based on the implementation for verifying the commit-graph, and a
copy-paste error kept the ERROR_COMMIT_GRAPH flag as the bit set
when an error appears in the multi-pack-index.
Add a new flag, ERROR_MULTI_PACK_INDEX, and use that instead.
Signed-off-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
