[gitweb feature request] Release snapshots with vX.X.X tags

> 	my $tagname = git_get_rev_name_tags($hash);
> 	my $tagversion = "";
> 	if ($tagname =~ m/^v(.+)\^0$/) {
>   	$tagversion = "-" + $1;
> 	}

> 
> 	if($tagversion)	{
> 		$filename .= "$tagversion$known_snapshot_formats{$format}{'suffix'}";
> 	}
> 	else	{
> 		$filename .= "-$hash$known_snapshot_formats{$format}{'suffix'}";
> 	}
> 

> I would like to create release snapshots with a git tag like "v0.0.1".
> For proper Debian packaging, a release snapshot of tag "v0.0.1" would
> have to be named "project-0.0.1.tar.gz" and contain a single directory
> with "project-0.0.1/" in the archive.
> 
> Attached is a very dirty patch to the current head of gitweb.perl to
> change the snapshot if the requested hash has a tag which matches
> "m/^v(.+)\^0$/". This regular expression will probably have to be more
> strict then that in the future, but my main concern is the quality of
> the patch, and whether or not this feature is something the mainstream
> would appreciate.
> 
> My question to you all is: would this feature be considered as an
> addition, and if so what would be the best way to get this patch into
> shape for inclusion?

> Bram Neijt <bneijt@gmail.com> writes:
> 
> > I would like to create release snapshots with a git tag like "v0.0.1".
> > For proper Debian packaging, a release snapshot of tag "v0.0.1" would
> > have to be named "project-0.0.1.tar.gz" and contain a single directory
> > with "project-0.0.1/" in the archive.
> > 
> > Attached is a very dirty patch to the current head of gitweb.perl to
> > change the snapshot if the requested hash has a tag which matches
> > "m/^v(.+)\^0$/". This regular expression will probably have to be more
> > strict then that in the future, but my main concern is the quality of
> > the patch, and whether or not this feature is something the mainstream
> > would appreciate.
> > 
> > My question to you all is: would this feature be considered as an
> > addition, and if so what would be the best way to get this patch into
> > shape for inclusion?
> 
> See Documentation/SubmittingPatches in git sources or in gitweb:
>   http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD
> Patch should be posted _inline_[1] (to make it easy to review the
> patch), and should use _unified_ (diff -u) format (to make it possible
> to apply patch correctly even if file changed in meantime) if you
> can't install git and use it (git format-patch) to generate a patch.
> 
> 
> By the way there is patch on git mailing list addressing part of
> mentioned issue:
>   "[PATCHv2 0/3] gitweb: Smarter snapshot names"
>   Message-ID: <1257606809-23287-1-git-send-email-jnareb@gmail.com>
>   http://thread.gmane.org/gmane.comp.version-control.git/132366
> (earlier version of this patch can be found in 'pu' branch as merge
> from 'mr/gitweb-snapshot' into pu).
> 
> This patch makes snapshot with name "project-version.tar.gz" to
> contain single directory "project-version/" in the archive.  Snapshot
> of tag *if requested* using 'refs/tags/v0.0.1' as 'h' (hash) parameter
> would have "project-v0.0.1.tar.gz" as proposed archive filename...
> but this patch doesn't make gitweb generate such links.
> 
> 
> [1] In very rare cases such as troubles with whitespace, line-wrapping
>     and encoding it might be better to attach it with text/plain
>     mimetype.
> 

> Bram Neijt <bneijt@gmail.com> writes:
> 
> > I would like to create release snapshots with a git tag like "v0.0.1".
> > For proper Debian packaging, a release snapshot of tag "v0.0.1" would
> > have to be named "project-0.0.1.tar.gz" and contain a single directory
> > with "project-0.0.1/" in the archive.
> 
> What the intended audience of this feature?  IOW,
> 
>  - who are going to "click" such a link on gitweb to obtain
>    project-0.0.1.tar.gz with project-0.0.1/?
> 
>  - how are they going to use that tarball?
> 
> I somehow suspect that they won't be the official Debian distro packagers.
> 
> Most likely they actually have a clone of the upstream project (how else
> they can stay up to date?  In addition they would want to track their own
> changes), so it would be more efficient for them to generate such a
> tarball from a tag, and more importantly, doing it locally means that they
> can they can verify the tag (and the whole history leading to it) before
> doing so, instead of relying on somebody else's gitweb.
> 
> You could be a mere Debian user who produces a *.deb for his own use out
> of such tarball, and in such a case you are a lot less likely be tracking
> the project (meaning, reading the history and keeping track of fixed bugs,
> new regressions and such) than just getting a snapshot that happens to be
> there and building it blindly, and I can understand it would be nicer if
> you did not have to unpack, rename and regenerate an archive.
> 
> Also, whose gitweb installations are you envisioning to enable this new
> feature?  Are you going to convince all the gitweb administrators of
> projects packaged by Debian (and derivatives) that have gitweb, and what
> are the incentive for these upstream projects to do so?  I would guess
> that most of the upstream projects do not consider Debian as their sole
> target distribution, and it would be a tough sell if changing the snapshot
> name to suit Debian breaks some other distro's (or human users) needs.
> 
> Jakub is polishing Mark's patch to change the snapshot name and contents
> hierarchy, but I think it won't satisfy Debian's naming guideline (it will
> have v0.0.1, not 0.0.1 in the name).  Changing the series's default to
> drop 'v' from the beginning of the tagname when the rest of it consists of
> all digits and dots would not be a correct solution, as Debian is not the
> only system in the world and other people may want different naming rules.
> 
> In order to make his series useful for your objective, it probably would
> require a bit more customizability, but because I cannot tell whom such a
> feature is really trying to help, and what the deployment plans are, I
> cannot judge if extra complexity to add such a customizability is worth
> it.  Also because there will be conflicts in the desired archive format
> ("Distro X people want this kind of archive, distro Y people want this
> different kind"), the choice somehow how to come from whoever is clicking
> the link, not from the gitweb administrator, and it probably would mean
> the codepath involved would need a lot more careful audit than just a
> server only "this gitweb installation would use this format"
> configuration.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

> I was going to comment inline but I think the general question can be
> read as "why would you want this?". For me it's just an extra bit of
> automation. It would keep me from having to make release tarballs. I
> would just refer all the users to a gitweb snapshot link of the "v..."
> tag. Having a release tarball with "projectname-version" with a single
> directory called "projectname-version/" in it is just good practice if
> you ask me.
> 
> Therefore it would benefit any developer like me :D : a spare time
> hobbyist who likes to automate as much of the administrative tasks, that
> go into running an open source project, as possible.
> 
> Greets,
>   Bram
> 
> PS I've found that cgit: http://hjemli.net/git/cgit/
> has this feature, so I'm probably going to give that a try and get back
> to you if I find any problems with it (the feature that is).
> 
> On Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:
>> Bram Neijt <bneijt@gmail.com> writes:
>>
>>> I would like to create release snapshots with a git tag like "v0.0.1".
>>> For proper Debian packaging, a release snapshot of tag "v0.0.1" would
>>> have to be named "project-0.0.1.tar.gz" and contain a single directory
>>> with "project-0.0.1/" in the archive.
>> What the intended audience of this feature?  IOW,
>>
>>  - who are going to "click" such a link on gitweb to obtain
>>    project-0.0.1.tar.gz with project-0.0.1/?
>>
>>  - how are they going to use that tarball?
>>
>> I somehow suspect that they won't be the official Debian distro packagers.
>>
>> Most likely they actually have a clone of the upstream project (how else
>> they can stay up to date?  In addition they would want to track their own
>> changes), so it would be more efficient for them to generate such a
>> tarball from a tag, and more importantly, doing it locally means that they
>> can they can verify the tag (and the whole history leading to it) before
>> doing so, instead of relying on somebody else's gitweb.
>>
>> You could be a mere Debian user who produces a *.deb for his own use out
>> of such tarball, and in such a case you are a lot less likely be tracking
>> the project (meaning, reading the history and keeping track of fixed bugs,
>> new regressions and such) than just getting a snapshot that happens to be
>> there and building it blindly, and I can understand it would be nicer if
>> you did not have to unpack, rename and regenerate an archive.
>>
>> Also, whose gitweb installations are you envisioning to enable this new
>> feature?  Are you going to convince all the gitweb administrators of
>> projects packaged by Debian (and derivatives) that have gitweb, and what
>> are the incentive for these upstream projects to do so?  I would guess
>> that most of the upstream projects do not consider Debian as their sole
>> target distribution, and it would be a tough sell if changing the snapshot
>> name to suit Debian breaks some other distro's (or human users) needs.
>>
>> Jakub is polishing Mark's patch to change the snapshot name and contents
>> hierarchy, but I think it won't satisfy Debian's naming guideline (it will
>> have v0.0.1, not 0.0.1 in the name).  Changing the series's default to
>> drop 'v' from the beginning of the tagname when the rest of it consists of
>> all digits and dots would not be a correct solution, as Debian is not the
>> only system in the world and other people may want different naming rules.
>>
>> In order to make his series useful for your objective, it probably would
>> require a bit more customizability, but because I cannot tell whom such a
>> feature is really trying to help, and what the deployment plans are, I
>> cannot judge if extra complexity to add such a customizability is worth
>> it.  Also because there will be conflicts in the desired archive format
>> ("Distro X people want this kind of archive, distro Y people want this
>> different kind"), the choice somehow how to come from whoever is clicking
>> the link, not from the gitweb administrator, and it probably would mean
>> the codepath involved would need a lot more careful audit than just a
>> server only "this gitweb installation would use this format"
>> configuration.
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html