From: john at keeping.me.uk (John Keeping)
Subject: [RFC/PATCH 0/7] Snapshot signatures
Date: Sat, 31 Mar 2018 16:35:47 +0100 [thread overview]
Message-ID: <cover.1522510150.git.john@keeping.me.uk> (raw)
Again, this isn't exactly what Konstantin asked for, but this approach
is easier to implement and I think achieves the main goal of exposing
signatures for snapshots.
The difference is that this approach has a notes ref for each archive
format and the note simply contains the signature content; there is no
additional metadata you just stick the signature in (for example)
refs/notes/signatures/tar.gz against the relevant tag object.
This disadvantage of this is that we only support a single signature
format, but I don't think that's a huge drawback as I expect any future
format to be obviously different so that we can easily inspect the
signature content to tell the difference.
The first 6 patches are refactoring which I think makes sense even
without the end goal of this series (they also fix an inconsistency
between snapshot links in the summary and commit pages). The series
builds on my "Custom snapshot prefix" series [1].
The final patch is the one that I expect feedback on; there's definitely
a lack of documentation but there's no point in writing that if this
approach is vetoed.
[1] https://lists.zx2c4.com/pipermail/cgit/2018-March/003767.html
John Keeping (7):
ui-refs: remove unnecessary sanity check
ui-shared: remove unused parameter
ui-shared: rename parameter to cgit_print_snapshot_links()
ui-shared: use the same snapshot logic as ui-refs
ui-shared: pass separator in to cgit_print_snapshot_links()
ui-refs: use shared function to print tag downloads
snapshot: support archive signatures
cgit.h | 2 ++
ui-commit.c | 2 +-
ui-refs.c | 30 +----------------------
ui-shared.c | 21 +++++++++++++----
ui-shared.h | 2 +-
ui-snapshot.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
ui-tag.c | 2 +-
7 files changed, 98 insertions(+), 37 deletions(-)
--
2.16.3
next reply other threads:[~2018-03-31 15:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-31 15:35 john [this message]
2018-03-31 15:35 ` [RFC/PATCH 1/7] ui-refs: remove unnecessary sanity check john
2018-03-31 15:35 ` [RFC/PATCH 2/7] ui-shared: remove unused parameter john
2018-03-31 15:35 ` [RFC/PATCH 3/7] ui-shared: rename parameter to cgit_print_snapshot_links() john
2018-03-31 15:35 ` [RFC/PATCH 4/7] ui-shared: use the same snapshot logic as ui-refs john
2018-03-31 15:35 ` [RFC/PATCH 5/7] ui-shared: pass separator in to cgit_print_snapshot_links() john
2018-03-31 15:35 ` [RFC/PATCH 6/7] ui-refs: use shared function to print tag downloads john
2018-03-31 15:35 ` [RFC/PATCH 7/7] snapshot: support archive signatures john
2018-04-02 21:22 ` [RFC/PATCH 0/7] Snapshot signatures konstantin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1522510150.git.john@keeping.me.uk \
--to=cgit@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).