Dear list members,
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?
Greetings,
Bram Neijt
Bram Neijt [off-list ref] 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: [off-list ref]
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.
--
Jakub Narebski
Poland
ShadeHawk on #git
Dear Jakub,
Thank you for your response, reading the thread you mentioned [1], I
have seen that my feature is already included in the patch in progress
there. I will simply wait for that patch to get through.
I hereby declare this thread closed.
Greetings,
Bram
[1] http://thread.gmane.org/gmane.comp.version-control.git/132366
On Sun, 2009-11-08 at 05:40 -0800, Jakub Narebski wrote:
Bram Neijt [off-list ref] writes:
quoted
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: [off-list ref]
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.