git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Matt McCutchen <hashproduct@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Petr Baudis <pasky@suse.cz>,
	Luben Tuikov <ltuikov@yahoo.com>
Subject: Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
Date: Thu, 19 Jul 2007 01:40:03 +0200	[thread overview]
Message-ID: <200707190140.05235.jnareb@gmail.com> (raw)
In-Reply-To: <1184699486.9831.7.camel@mattlaptop2>

On Tue, 17 July 2007, Matt McCutchen napisał:
> - Centralize knowledge about snapshot formats (mime types, extensions,
>   commands) in %known_snapshot_formats and improve how some of that
>   information is specified.  In particular, zip files are no longer a
>   special case.
> 
> - Add support for offering multiple snapshot formats to the user so
>   that he/she can download a snapshot in the format he/she prefers.
>   The site-wide or project configuration now gives a list of formats
>   to offer, and if more than one format is offered, the "_snapshot_"
>   link becomes something like "snapshot (_tar.bz2_ _zip_)".
> 
> - If only one format is offered, a tooltip on the "_snapshot_" link
>   tells the user what it is.

Nice idea.

> - Fix out-of-date "tarball" -> "archive" in comment.
> 
> Alert for gitweb site administrators: This patch changes the format of
> $feature{'snapshot'}{'default'} in gitweb_config.perl from a list of
> three pieces of information about a single format to a list of one or
> more formats you wish to offer from the set ('tgz', 'tbz2', 'zip').
> Update your gitweb_config.perl appropriately.  The preferred names for
> gitweb.snapshot in repository configuration have also changed from
> 'gzip' and 'bzip2' to 'tgz' and 'tbz2', but the old names are still
> recognized for compatibility.

This alert/warning should probably be put in RelNotes for when it would
be in git.git

> Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
> ---
> 
> Changes since the previous revision of the patch:
> 
> - Added display names.
> - Changed compressor command line to list form.
> - Added compatibility format aliases for repository configuration.
> - Tweaked filtering of unknown formats to apply only to repository
>   configuration.
> - Reformatted format_snapshot_links and added/modified comments to make it much
>   easier to understand.
> - When a single snapshot format is offered, added a tooltip showing the format
>   to the "snapshot" link.  This helps Junio's hypothetical end user without
>   using additional screen real estate.
> 
> I thought of another incompatibility: previously bookmarked snapshot
> URLs will no longer work because they lack the new "sf" parameter.  I
> don't care about this; do any of you?

I think either having good error message, or using first format avaiable
would be good enough.

> +# information about snapshot formats that gitweb is capable of serving
> +# name => [display name, mime type, filename suffix, --format for git-archive,
> +#          [compressor command and arguments] | undef]
> +our %known_snapshot_formats = (
> +	'tgz'  => ['tar.gz' , 'application/x-gzip' , '.tar.gz' , 'tar', ['gzip' ]],
> +	'tbz2' => ['tar.bz2', 'application/x-bzip2', '.tar.bz2', 'tar', ['bzip2']],
> +	'zip'  => ['zip',     'application/x-zip'  , '.zip'    , 'zip', undef    ],
> +);

First I'm not sure if we want to do the way it had to be done when
those info was in the subfield of %feature hash, or to imitate %feature
hash using instead:

+our %known_snapshot_formats = (
+	'tgz'  => {
+		'display'  => 'tar.gz',
+		'mimetype' => 'application/x-gzip',
+		'suffix'   => '.tar.gz',
+		'format'   => 'tar',
+		'compressor' => ['gzip' ]},
... 

which means that when using %known_snapshot_formats we don't have
to remember for example which of the elements in array is mimetype,
which display name, and which format to be passed to git-archive.


Second, I have thought that we might want to simply use the rest of
array for the compressor and it's arguments instead of adding it as
anonymous array reference (inner array). But this way we could in
princile add more pipelines... although I think it would be not useful.
I'd rather have first option implemented, even if it does not allow for
multiple pipelines.

Third, I think we don't need to say "undef" explicitely, I think.
"defined ('a')[1]" returns the same as "defined ('a', undef)[1]".

> +# Aliases so we understand old gitweb.snapshot values in repository
> +# configuration.
> +our %known_snapshot_format_aliases = (
> +	'gzip'  => 'tgz' ,
> +	'bzip2' => 'tbz2',
> +);

Good idea, better than tring to fit it in %known_snapshot_formats.

-- 
Jakub Narebski
Poland

  reply	other threads:[~2007-07-18 23:33 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-28 18:02 [PATCH] gitweb: snapshot cleanups & support for offering multiple formats Matt McCutchen
2007-07-07 20:52 ` Junio C Hamano
2007-07-08  9:06   ` Junio C Hamano
2007-07-11 15:55   ` Jakub Narebski
2007-07-11 21:26     ` Junio C Hamano
2007-07-12  1:15       ` Matt McCutchen
2007-07-12 11:07         ` Jakub Narebski
2007-07-17 18:03           ` Matt McCutchen
2007-07-17 19:11             ` Matt McCutchen
2007-07-18 23:40               ` Jakub Narebski [this message]
2007-07-19  1:12                 ` Junio C Hamano
2007-07-19  3:30                   ` Luben Tuikov
2007-07-19  7:30                     ` Jakub Narebski
2007-07-19  7:40                       ` Luben Tuikov
2007-07-25 18:39                         ` [RFC/PATCH] gitweb: Enable transparent compression form HTTP output Jakub Narebski
2007-08-25 18:03                           ` Petr Baudis
2007-08-25 22:09                             ` Jakub Narebski
2007-08-25 22:14                               ` Petr Baudis
2007-08-27 11:01                                 ` Jakub Narebski
2007-07-19  9:05                   ` [PATCH] gitweb: snapshot cleanups & support for offering multiple formats Jakub Narebski
2007-07-20  4:29                     ` Junio C Hamano
2007-07-19  9:14               ` Jakub Narebski
2007-07-21 23:30               ` Jakub Narebski
2007-07-22  5:26                 ` Junio C Hamano
2007-07-22 15:05                   ` Matt McCutchen
2007-07-22 21:41                     ` [PATCH] gitweb: Fix support for legacy gitweb config for snapshots Jakub Narebski
2007-07-22 23:10                       ` Matt McCutchen
2007-07-22 23:35                         ` Junio C Hamano
2007-07-08 21:54 ` [PATCH] gitweb: snapshot cleanups & support for offering multiple formats Junio C Hamano
2007-07-09 22:52   ` Matt McCutchen
2007-07-09 23:21     ` Matt McCutchen
2007-07-10 23:41       ` Jakub Narebski
2007-07-09 23:48     ` Junio C Hamano
2007-07-10  1:14       ` Matt McCutchen
2007-07-10  1:14       ` Matt McCutchen

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200707190140.05235.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hashproduct@gmail.com \
    --cc=ltuikov@yahoo.com \
    --cc=pasky@suse.cz \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).