Custom snapshot prefix & Snapshot signatures

John Keeping john at keeping.me.uk
Thu Jun 7 15:10:47 CEST 2018


On Thu, Jun 07, 2018 at 02:12:51PM +0200, Christian Hesse wrote:
> Hello everybody,
> 
> I missed to reply in time and my mail client decided to purge old mails from
> my mailing list folders. (Well, I told it to do so regularly.)
> So breaking the threads and reviewing in this mail. Sorry!
> 
> First of all let me say that I really love this! The snapshot signatures
> feature allows to get rid of uploading static tarballs and signatures,
> handling everything from your command line with git. Thanks a lot for your
> marvelous work, John!
> 
> I do agree with Konstantin, though: Binary compressed data may change over
> time with more recent algorithms. So I will reply with an extra patch that
> allows to push tar signatures to git notes that can be downloaded for
> compressed tar snapshots.
> 
> Custom snapshot prefix [0]:
> John Keeping (3):
>   ui-shared: pass repo object to print_snapshot_links()
>   ui-snapshot: pass repo into get_ref_from_filename()
>   Add "snapshot-prefix" repo configuration
> 
> All these look good to me. Please add my Reviewed-by!
> 
> Snapshot signatures [1]:
> 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
> 
> All these look good to me. Please add my Reviewed-by!
> 
>   snapshot: support archive signatures
> 
> > @@ -129,6 +154,39 @@ static int make_snapshot(const struct
> > cgit_snapshot_format *format, return 0;
> >  }
> > 
> > +static int write_sig(const struct cgit_snapshot_format *format,
> > +		     const char *hex, const char *archive,
> > +		     const char *filename)
> > +{
> > +	const struct object_id *note = cgit_snapshot_get_sig(hex, format);
> 
> Do we mix declaration and code? Let's get this separated.

I think this is fine, it isn't decl-after-statement which is what we
object to.  Initialize-at-declaration is common in git.git and in CGit.

> > +	enum object_type type;
> > +	unsigned long size;
> > +	char *buf;
> > [...]
> 
> But this is just nit-picking, so please add my Reviewed-by!
> 
> This will need some changes when updating to git v2.18.0. Would be nice to
> have this in soon so I can rebase my commit.
> 
> [0] https://lists.zx2c4.com/pipermail/cgit/2018-March/003767.html
> [1] https://lists.zx2c4.com/pipermail/cgit/2018-March/003772.html


More information about the CGit mailing list