{"thread":{"id":"21530","subject":"[gitweb feature request] Release snapshots with vX.X.X tags","startedAt":"2009-11-08T11:40:42Z","lastAt":"2009-11-08T21:27:51Z","messageCount":6,"participants":["Bram Neijt","Jakub Narebski","Junio C Hamano","J.H."],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"127071","messageId":"1257680442.14087.78.camel@owl","threadId":"21530","inReplyTo":null,"subject":"[gitweb feature request] Release snapshots with vX.X.X tags","fromName":"Bram Neijt","fromEmail":"bneijt@gmail.com","sentAt":"2009-11-08T11:40:42Z","receivedAt":"2009-11-08T11:40:42Z","isPatch":false,"sender":{"key":"bneijt@gmail.com","avatar":"https://gravatar.com/avatar/fdfbeb0132f336b393e621e6cfae0fe66003f4bd74c6453e774e095f4c87a1c3?d=mp&s=160"},"body":"Dear list members,\n\nI would like to create release snapshots with a git tag like \"v0.0.1\".\nFor proper Debian packaging, a release snapshot of tag \"v0.0.1\" would\nhave to be named \"project-0.0.1.tar.gz\" and contain a single directory\nwith \"project-0.0.1/\" in the archive.\n\nAttached is a very dirty patch to the current head of gitweb.perl to\nchange the snapshot if the requested hash has a tag which matches\n\"m/^v(.+)\\^0$/\". This regular expression will probably have to be more\nstrict then that in the future, but my main concern is the quality of\nthe patch, and whether or not this feature is something the mainstream\nwould appreciate.\n\nMy question to you all is: would this feature be considered as an\naddition, and if so what would be the best way to get this patch into\nshape for inclusion?\n\nGreetings,\n Bram Neijt\n\n\n\n5269a5270,5274\n> \tmy $tagname = git_get_rev_name_tags($hash);\n> \tmy $tagversion = \"\";\n> \tif ($tagname =~ m/^v(.+)\\^0$/) {\n> \t$tagversion = \"-\" + $1;\n> \t}\n5275a5281,5288\n> \n> \tif($tagversion)\t{\n> \t\t$filename .= \"$tagversion$known_snapshot_formats{$format}{'suffix'}\";\n> \t}\n> \telse\t{\n> \t\t$filename .= \"-$hash$known_snapshot_formats{$format}{'suffix'}\";\n> \t}\n> \n5281c5294\n< \t\t\"--prefix=$name/\", $hash);\n---\n> \t\t\"--prefix=$name$tagversion/\", $hash);\n"},{"id":"127078","messageId":"m3tyx5rv6j.fsf@localhost.localdomain","threadId":"21530","inReplyTo":"1257680442.14087.78.camel@owl","subject":"Re: [gitweb feature request] Release snapshots with vX.X.X tags","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-08T13:40:54Z","receivedAt":"2009-11-08T13:40:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Bram Neijt writes:\n\n> I would like to create release snapshots with a git tag like \"v0.0.1\".\n> For proper Debian packaging, a release snapshot of tag \"v0.0.1\" would\n> have to be named \"project-0.0.1.tar.gz\" and contain a single directory\n> with \"project-0.0.1/\" in the archive.\n> \n> Attached is a very dirty patch to the current head of gitweb.perl to\n> change the snapshot if the requested hash has a tag which matches\n> \"m/^v(.+)\\^0$/\". This regular expression will probably have to be more\n> strict then that in the future, but my main concern is the quality of\n> the patch, and whether or not this feature is something the mainstream\n> would appreciate.\n> \n> My question to you all is: would this feature be considered as an\n> addition, and if so what would be the best way to get this patch into\n> shape for inclusion?\n\nSee Documentation/SubmittingPatches in git sources or in gitweb:\n http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD\nPatch should be posted _inline_[1] (to make it easy to review the\npatch), and should use _unified_ (diff -u) format (to make it possible\nto apply patch correctly even if file changed in meantime) if you\ncan't install git and use it (git format-patch) to generate a patch.\n\n\nBy the way there is patch on git mailing list addressing part of\nmentioned issue:\n \"[PATCHv2 0/3] gitweb: Smarter snapshot names\"\n Message-ID: <1257606809-23287-1-git-send-email-jnareb@gmail.com>\n http://thread.gmane.org/gmane.comp.version-control.git/132366\n(earlier version of this patch can be found in 'pu' branch as merge\nfrom 'mr/gitweb-snapshot' into pu).\n\nThis patch makes snapshot with name \"project-version.tar.gz\" to\ncontain single directory \"project-version/\" in the archive. Snapshot\nof tag *if requested* using 'refs/tags/v0.0.1' as 'h' (hash) parameter\nwould have \"project-v0.0.1.tar.gz\" as proposed archive filename...\nbut this patch doesn't make gitweb generate such links.\n\n\n[1] In very rare cases such as troubles with whitespace, line-wrapping\n and encoding it might be better to attach it with text/plain\n mimetype.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"127079","messageId":"1257689751.14087.89.camel@owl","threadId":"21530","inReplyTo":"m3tyx5rv6j.fsf@localhost.localdomain","subject":"Re: [gitweb feature request] Release snapshots with vX.X.X tags [closed]","fromName":"Bram Neijt","fromEmail":"bneijt@gmail.com","sentAt":"2009-11-08T14:15:51Z","receivedAt":"2009-11-08T14:15:51Z","isPatch":false,"sender":{"key":"bneijt@gmail.com","avatar":"https://gravatar.com/avatar/fdfbeb0132f336b393e621e6cfae0fe66003f4bd74c6453e774e095f4c87a1c3?d=mp&s=160"},"body":"Dear Jakub,\n\nThank you for your response, reading the thread you mentioned [1], I\nhave seen that my feature is already included in the patch in progress\nthere. I will simply wait for that patch to get through.\n\nI hereby declare this thread closed.\n\nGreetings,\n Bram\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/132366\n\nOn Sun, 2009-11-08 at 05:40 -0800, Jakub Narebski wrote:\n> Bram Neijt writes:\n> \n> > I would like to create release snapshots with a git tag like \"v0.0.1\".\n> > For proper Debian packaging, a release snapshot of tag \"v0.0.1\" would\n> > have to be named \"project-0.0.1.tar.gz\" and contain a single directory\n> > with \"project-0.0.1/\" in the archive.\n> > \n> > Attached is a very dirty patch to the current head of gitweb.perl to\n> > change the snapshot if the requested hash has a tag which matches\n> > \"m/^v(.+)\\^0$/\". This regular expression will probably have to be more\n> > strict then that in the future, but my main concern is the quality of\n> > the patch, and whether or not this feature is something the mainstream\n> > would appreciate.\n> > \n> > My question to you all is: would this feature be considered as an\n> > addition, and if so what would be the best way to get this patch into\n> > shape for inclusion?\n> \n> See Documentation/SubmittingPatches in git sources or in gitweb:\n> http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD\n> Patch should be posted _inline_[1] (to make it easy to review the\n> patch), and should use _unified_ (diff -u) format (to make it possible\n> to apply patch correctly even if file changed in meantime) if you\n> can't install git and use it (git format-patch) to generate a patch.\n> \n> \n> By the way there is patch on git mailing list addressing part of\n> mentioned issue:\n> \"[PATCHv2 0/3] gitweb: Smarter snapshot names\"\n> Message-ID: <1257606809-23287-1-git-send-email-jnareb@gmail.com>\n> http://thread.gmane.org/gmane.comp.version-control.git/132366\n> (earlier version of this patch can be found in 'pu' branch as merge\n> from 'mr/gitweb-snapshot' into pu).\n> \n> This patch makes snapshot with name \"project-version.tar.gz\" to\n> contain single directory \"project-version/\" in the archive. Snapshot\n> of tag *if requested* using 'refs/tags/v0.0.1' as 'h' (hash) parameter\n> would have \"project-v0.0.1.tar.gz\" as proposed archive filename...\n> but this patch doesn't make gitweb generate such links.\n> \n> \n> [1] In very rare cases such as troubles with whitespace, line-wrapping\n> and encoding it might be better to attach it with text/plain\n> mimetype.\n> \n"},{"id":"127088","messageId":"7vbpjcetlp.fsf@alter.siamese.dyndns.org","threadId":"21530","inReplyTo":"1257680442.14087.78.camel@owl","subject":"Re: [gitweb feature request] Release snapshots with vX.X.X tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-08T18:53:22Z","receivedAt":"2009-11-08T18:53:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bram Neijt writes:\n\n> I would like to create release snapshots with a git tag like \"v0.0.1\".\n> For proper Debian packaging, a release snapshot of tag \"v0.0.1\" would\n> have to be named \"project-0.0.1.tar.gz\" and contain a single directory\n> with \"project-0.0.1/\" in the archive.\n\nWhat the intended audience of this feature? IOW,\n\n - who are going to \"click\" such a link on gitweb to obtain\n project-0.0.1.tar.gz with project-0.0.1/?\n\n - how are they going to use that tarball?\n\nI somehow suspect that they won't be the official Debian distro packagers.\n\nMost likely they actually have a clone of the upstream project (how else\nthey can stay up to date? In addition they would want to track their own\nchanges), so it would be more efficient for them to generate such a\ntarball from a tag, and more importantly, doing it locally means that they\ncan they can verify the tag (and the whole history leading to it) before\ndoing so, instead of relying on somebody else's gitweb.\n\nYou could be a mere Debian user who produces a *.deb for his own use out\nof such tarball, and in such a case you are a lot less likely be tracking\nthe project (meaning, reading the history and keeping track of fixed bugs,\nnew regressions and such) than just getting a snapshot that happens to be\nthere and building it blindly, and I can understand it would be nicer if\nyou did not have to unpack, rename and regenerate an archive.\n\nAlso, whose gitweb installations are you envisioning to enable this new\nfeature? Are you going to convince all the gitweb administrators of\nprojects packaged by Debian (and derivatives) that have gitweb, and what\nare the incentive for these upstream projects to do so? I would guess\nthat most of the upstream projects do not consider Debian as their sole\ntarget distribution, and it would be a tough sell if changing the snapshot\nname to suit Debian breaks some other distro's (or human users) needs.\n\nJakub is polishing Mark's patch to change the snapshot name and contents\nhierarchy, but I think it won't satisfy Debian's naming guideline (it will\nhave v0.0.1, not 0.0.1 in the name). Changing the series's default to\ndrop 'v' from the beginning of the tagname when the rest of it consists of\nall digits and dots would not be a correct solution, as Debian is not the\nonly system in the world and other people may want different naming rules.\n\nIn order to make his series useful for your objective, it probably would\nrequire a bit more customizability, but because I cannot tell whom such a\nfeature is really trying to help, and what the deployment plans are, I\ncannot judge if extra complexity to add such a customizability is worth\nit. Also because there will be conflicts in the desired archive format\n(\"Distro X people want this kind of archive, distro Y people want this\ndifferent kind\"), the choice somehow how to come from whoever is clicking\nthe link, not from the gitweb administrator, and it probably would mean\nthe codepath involved would need a lot more careful audit than just a\nserver only \"this gitweb installation would use this format\"\nconfiguration.\n"},{"id":"127094","messageId":"1257714522.14087.133.camel@owl","threadId":"21530","inReplyTo":"7vbpjcetlp.fsf@alter.siamese.dyndns.org","subject":"Re: [gitweb feature request] Release snapshots with vX.X.X tags","fromName":"Bram Neijt","fromEmail":"bneijt@gmail.com","sentAt":"2009-11-08T21:08:42Z","receivedAt":"2009-11-08T21:08:42Z","isPatch":false,"sender":{"key":"bneijt@gmail.com","avatar":"https://gravatar.com/avatar/fdfbeb0132f336b393e621e6cfae0fe66003f4bd74c6453e774e095f4c87a1c3?d=mp&s=160"},"body":"I was going to comment inline but I think the general question can be\nread as \"why would you want this?\". For me it's just an extra bit of\nautomation. It would keep me from having to make release tarballs. I\nwould just refer all the users to a gitweb snapshot link of the \"v...\"\ntag. Having a release tarball with \"projectname-version\" with a single\ndirectory called \"projectname-version/\" in it is just good practice if\nyou ask me.\n\nTherefore it would benefit any developer like me :D : a spare time\nhobbyist who likes to automate as much of the administrative tasks, that\ngo into running an open source project, as possible.\n\nGreets,\n Bram\n\nPS I've found that cgit: http://hjemli.net/git/cgit/\nhas this feature, so I'm probably going to give that a try and get back\nto you if I find any problems with it (the feature that is).\n\nOn Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:\n> Bram Neijt writes:\n> \n> > I would like to create release snapshots with a git tag like \"v0.0.1\".\n> > For proper Debian packaging, a release snapshot of tag \"v0.0.1\" would\n> > have to be named \"project-0.0.1.tar.gz\" and contain a single directory\n> > with \"project-0.0.1/\" in the archive.\n> \n> What the intended audience of this feature? IOW,\n> \n> - who are going to \"click\" such a link on gitweb to obtain\n> project-0.0.1.tar.gz with project-0.0.1/?\n> \n> - how are they going to use that tarball?\n> \n> I somehow suspect that they won't be the official Debian distro packagers.\n> \n> Most likely they actually have a clone of the upstream project (how else\n> they can stay up to date? In addition they would want to track their own\n> changes), so it would be more efficient for them to generate such a\n> tarball from a tag, and more importantly, doing it locally means that they\n> can they can verify the tag (and the whole history leading to it) before\n> doing so, instead of relying on somebody else's gitweb.\n> \n> You could be a mere Debian user who produces a *.deb for his own use out\n> of such tarball, and in such a case you are a lot less likely be tracking\n> the project (meaning, reading the history and keeping track of fixed bugs,\n> new regressions and such) than just getting a snapshot that happens to be\n> there and building it blindly, and I can understand it would be nicer if\n> you did not have to unpack, rename and regenerate an archive.\n> \n> Also, whose gitweb installations are you envisioning to enable this new\n> feature? Are you going to convince all the gitweb administrators of\n> projects packaged by Debian (and derivatives) that have gitweb, and what\n> are the incentive for these upstream projects to do so? I would guess\n> that most of the upstream projects do not consider Debian as their sole\n> target distribution, and it would be a tough sell if changing the snapshot\n> name to suit Debian breaks some other distro's (or human users) needs.\n> \n> Jakub is polishing Mark's patch to change the snapshot name and contents\n> hierarchy, but I think it won't satisfy Debian's naming guideline (it will\n> have v0.0.1, not 0.0.1 in the name). Changing the series's default to\n> drop 'v' from the beginning of the tagname when the rest of it consists of\n> all digits and dots would not be a correct solution, as Debian is not the\n> only system in the world and other people may want different naming rules.\n> \n> In order to make his series useful for your objective, it probably would\n> require a bit more customizability, but because I cannot tell whom such a\n> feature is really trying to help, and what the deployment plans are, I\n> cannot judge if extra complexity to add such a customizability is worth\n> it. Also because there will be conflicts in the desired archive format\n> (\"Distro X people want this kind of archive, distro Y people want this\n> different kind\"), the choice somehow how to come from whoever is clicking\n> the link, not from the gitweb administrator, and it probably would mean\n> the codepath involved would need a lot more careful audit than just a\n> server only \"this gitweb installation would use this format\"\n> configuration.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"127096","messageId":"4AF737D7.8030203@eaglescrag.net","threadId":"21530","inReplyTo":"1257714522.14087.133.camel@owl","subject":"Re: [gitweb feature request] Release snapshots with vX.X.X tags","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2009-11-08T21:27:51Z","receivedAt":"2009-11-08T21:27:51Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"Bram,\n\nThis is true, but gitweb, in it's current incarnation, is *SLOW* using \nit as a primary distribution means is ludicrous. Regenerating a tarball \non each request will destroy a server, plain and simple. Git/Gitweb \nshould *NOT* be used in place of doing properly release engineering.\n\nIf Debian requires their tarballs to be done up in a certain way, this \nis either the problem of the packager, or if you want to be kind create \na makefile target that will generate this and release both when you do a \nrelease:\n\nI.E.\n\n# make release\nGenerating Normal Tarball: -.tar.gz\nGenerating Debian Tarball: -.deb.tar.gz\n# ls\nMakefile -.tar.gz -.deb.tar.gz src/\n#\n\nThen take your releases and put them on your release server.\n\n- John 'Warthog9' Hawley\n\nBram Neijt wrote:\n> I was going to comment inline but I think the general question can be\n> read as \"why would you want this?\". For me it's just an extra bit of\n> automation. It would keep me from having to make release tarballs. I\n> would just refer all the users to a gitweb snapshot link of the \"v...\"\n> tag. Having a release tarball with \"projectname-version\" with a single\n> directory called \"projectname-version/\" in it is just good practice if\n> you ask me.\n> \n> Therefore it would benefit any developer like me :D : a spare time\n> hobbyist who likes to automate as much of the administrative tasks, that\n> go into running an open source project, as possible.\n> \n> Greets,\n> Bram\n> \n> PS I've found that cgit: http://hjemli.net/git/cgit/\n> has this feature, so I'm probably going to give that a try and get back\n> to you if I find any problems with it (the feature that is).\n> \n> On Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:\n>> Bram Neijt writes:\n>>\n>>> I would like to create release snapshots with a git tag like \"v0.0.1\".\n>>> For proper Debian packaging, a release snapshot of tag \"v0.0.1\" would\n>>> have to be named \"project-0.0.1.tar.gz\" and contain a single directory\n>>> with \"project-0.0.1/\" in the archive.\n>> What the intended audience of this feature? IOW,\n>>\n>> - who are going to \"click\" such a link on gitweb to obtain\n>> project-0.0.1.tar.gz with project-0.0.1/?\n>>\n>> - how are they going to use that tarball?\n>>\n>> I somehow suspect that they won't be the official Debian distro packagers.\n>>\n>> Most likely they actually have a clone of the upstream project (how else\n>> they can stay up to date? In addition they would want to track their own\n>> changes), so it would be more efficient for them to generate such a\n>> tarball from a tag, and more importantly, doing it locally means that they\n>> can they can verify the tag (and the whole history leading to it) before\n>> doing so, instead of relying on somebody else's gitweb.\n>>\n>> You could be a mere Debian user who produces a *.deb for his own use out\n>> of such tarball, and in such a case you are a lot less likely be tracking\n>> the project (meaning, reading the history and keeping track of fixed bugs,\n>> new regressions and such) than just getting a snapshot that happens to be\n>> there and building it blindly, and I can understand it would be nicer if\n>> you did not have to unpack, rename and regenerate an archive.\n>>\n>> Also, whose gitweb installations are you envisioning to enable this new\n>> feature? Are you going to convince all the gitweb administrators of\n>> projects packaged by Debian (and derivatives) that have gitweb, and what\n>> are the incentive for these upstream projects to do so? I would guess\n>> that most of the upstream projects do not consider Debian as their sole\n>> target distribution, and it would be a tough sell if changing the snapshot\n>> name to suit Debian breaks some other distro's (or human users) needs.\n>>\n>> Jakub is polishing Mark's patch to change the snapshot name and contents\n>> hierarchy, but I think it won't satisfy Debian's naming guideline (it will\n>> have v0.0.1, not 0.0.1 in the name). Changing the series's default to\n>> drop 'v' from the beginning of the tagname when the rest of it consists of\n>> all digits and dots would not be a correct solution, as Debian is not the\n>> only system in the world and other people may want different naming rules.\n>>\n>> In order to make his series useful for your objective, it probably would\n>> require a bit more customizability, but because I cannot tell whom such a\n>> feature is really trying to help, and what the deployment plans are, I\n>> cannot judge if extra complexity to add such a customizability is worth\n>> it. Also because there will be conflicts in the desired archive format\n>> (\"Distro X people want this kind of archive, distro Y people want this\n>> different kind\"), the choice somehow how to come from whoever is clicking\n>> the link, not from the gitweb administrator, and it probably would mean\n>> the codepath involved would need a lot more careful audit than just a\n>> server only \"this gitweb installation would use this format\"\n>> configuration.\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"}]}