interesting, I used a different commit id today and it works. However if I use the instructions on the page to get the right commit it doesn't.
Ie if I use git rev-parse $TAG I get a commit id which will not work when substituted above. Intead if I do git log -1 $TAG and use the commit id of the tagged commit it works. I wonder if the instructions have always been wrong or if they change something subtler in github and now only the tag ids do not work anymore ...
Hi Simo,
Interesting. I can't speak to the use of get rev-parse vs. git log since I always grabbed the commit hash from the webpage (I know, I know, I'll hand in my l33t h4x0r card next meeting, I swear).
Regards, Jeff
On 22/09/14 12:58, Jeff Backus wrote:
interesting, I used a different commit id today and it works. However if I use the instructions on the page to get the right commit it doesn't. Ie if I use git rev-parse $TAG I get a commit id which will not work when substituted above. Intead if I do git log -1 $TAG and use the commit id of the tagged commit it works. I wonder if the instructions have always been wrong or if they change something subtler in github and now only the tag ids do not work anymore ...
Hi Simo,
Interesting. I can't speak to the use of get rev-parse vs. git log since I always grabbed the commit hash from the webpage (I know, I know, I'll hand in my l33t h4x0r card next meeting, I swear).
The git rev-parse command is giving you the ID of the tag, not the ID of the commit that the tag points at.
Tom
On 22/09/14 13:48, Tom Hughes wrote:
On 22/09/14 12:58, Jeff Backus wrote:
interesting, I used a different commit id today and it works. However if I use the instructions on the page to get the right commit it doesn't. Ie if I use git rev-parse $TAG I get a commit id which will not work when substituted above. Intead if I do git log -1 $TAG and use the commit id of the tagged commit it works. I wonder if the instructions have always been wrong or if they change something subtler in github and now only the tag ids do not work anymore ...
Hi Simo,
Interesting. I can't speak to the use of get rev-parse vs. git log since I always grabbed the commit hash from the webpage (I know, I know, I'll hand in my l33t h4x0r card next meeting, I swear).
The git rev-parse command is giving you the ID of the tag, not the ID of the commit that the tag points at.
Specifically this happens because it is an annotated tag, which is a first class object with a creation date, author, comment and optional gpg signature.
With a simple tag the rev-parse thing would work.
Tom
On Mon, 22 Sep 2014 13:52:20 +0100 Tom Hughes tom@compton.nu wrote:
On 22/09/14 13:48, Tom Hughes wrote:
On 22/09/14 12:58, Jeff Backus wrote:
interesting, I used a different commit id today and it works. However if I use the instructions on the page to get the right
commit it doesn't.
Ie if I use git rev-parse $TAG I get a commit id which will
not work when substituted above. Intead if I do git log -1 $TAG and use the commit id of the tagged commit it works. I wonder if the instructions have always been wrong or if they change something subtler in github and now only the tag ids do not work anymore ...
Hi Simo,
Interesting. I can't speak to the use of get rev-parse vs. git log since I always grabbed the commit hash from the webpage (I know, I know, I'll hand in my l33t h4x0r card next meeting, I swear).
The git rev-parse command is giving you the ID of the tag, not the ID of the commit that the tag points at.
Specifically this happens because it is an annotated tag, which is a first class object with a creation date, author, comment and optional gpg signature.
With a simple tag the rev-parse thing would work.
Yes, that's the point, I guess whoever put up the original instructions didn't know the difference and did not test with annotated tags. perhaps we should amend the instructions there ?
The annotated tag issue may have been the only issue here, maybe github never properly resolved annotated tags.
Simo.
Hi all, I have just come across this thread, but have not read it yet. I just want to mention, that there is simple web service (made by me) to perform redirects to github. See http://srcurl.net/ I use theese urls in my spec files.
Regards, QB
----- Original Message ----- From: "Simo Sorce" ssorce@redhat.com To: "Tom Hughes" tom@compton.nu Cc: "Discussion of RPM packaging standards and practices for Fedora" packaging@lists.fedoraproject.org Sent: Monday, September 22, 2014 3:53:21 PM Subject: [Fedora-packaging] Source0 for github ?
On Mon, 22 Sep 2014 13:52:20 +0100 Tom Hughes tom@compton.nu wrote:
On 22/09/14 13:48, Tom Hughes wrote:
On 22/09/14 12:58, Jeff Backus wrote:
interesting, I used a different commit id today and it works. However if I use the instructions on the page to get the right
commit it doesn't.
Ie if I use git rev-parse $TAG I get a commit id which will
not work when substituted above. Intead if I do git log -1 $TAG and use the commit id of the tagged commit it works. I wonder if the instructions have always been wrong or if they change something subtler in github and now only the tag ids do not work anymore ...
Hi Simo,
Interesting. I can't speak to the use of get rev-parse vs. git log since I always grabbed the commit hash from the webpage (I know, I know, I'll hand in my l33t h4x0r card next meeting, I swear).
The git rev-parse command is giving you the ID of the tag, not the ID of the commit that the tag points at.
Specifically this happens because it is an annotated tag, which is a first class object with a creation date, author, comment and optional gpg signature.
With a simple tag the rev-parse thing would work.
Yes, that's the point, I guess whoever put up the original instructions didn't know the difference and did not test with annotated tags. perhaps we should amend the instructions there ?
The annotated tag issue may have been the only issue here, maybe github never properly resolved annotated tags.
Simo.
On Mon, 22 Sep 2014 13:12:00 -0400 (EDT) Jakub QB Dorňák jdornak@redhat.com wrote:
Hi all, I have just come across this thread, but have not read it yet. I just want to mention, that there is simple web service (made by me) to perform redirects to github. See http://srcurl.net/ I use theese urls in my spec files.
Regards, QB
----- Original Message ----- From: "Simo Sorce" ssorce@redhat.com To: "Tom Hughes" tom@compton.nu Cc: "Discussion of RPM packaging standards and practices for Fedora" packaging@lists.fedoraproject.org Sent: Monday, September 22, 2014 3:53:21 PM Subject: [Fedora-packaging] Source0 for github ?
On Mon, 22 Sep 2014 13:52:20 +0100 Tom Hughes tom@compton.nu wrote:
On 22/09/14 13:48, Tom Hughes wrote:
On 22/09/14 12:58, Jeff Backus wrote:
interesting, I used a different commit id today and it works. However if I use the instructions on the page to get the
right commit it doesn't.
Ie if I use git rev-parse $TAG I get a commit id which will
not work when substituted above. Intead if I do git log -1 $TAG and use the commit id of the tagged commit it works. I wonder if the instructions have always been wrong or if they change something subtler in github and now only the tag ids do not work anymore ...
Hi Simo,
Interesting. I can't speak to the use of get rev-parse vs. git log since I always grabbed the commit hash from the webpage (I know, I know, I'll hand in my l33t h4x0r card next meeting, I swear).
The git rev-parse command is giving you the ID of the tag, not the ID of the commit that the tag points at.
Specifically this happens because it is an annotated tag, which is a first class object with a creation date, author, comment and optional gpg signature.
With a simple tag the rev-parse thing would work.
Yes, that's the point, I guess whoever put up the original instructions didn't know the difference and did not test with annotated tags. perhaps we should amend the instructions there ?
The annotated tag issue may have been the only issue here, maybe github never properly resolved annotated tags.
If it is ok to use it in Fedora spec files, I would gladly do so, I hate the tarball name with the commitid into it.
Simo.
packaging@lists.fedoraproject.org