Dne 21.1.2014 18:01, Kaleb KEITHLEY napsal(a):
Take, for example,
https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a
button for Source code (tar.gz) pointing at
https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
Note V2.0.0.tar.gz versus
Indeed, as well as in other places e. g., the iconcache snippets.
--alec
On 1/27/14, Vít Ondruch vondr...@redhat.com wrote:
Dne 21.1.2014 18:01, Kaleb KEITHLEY napsal(a):
Take, for example,
https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a
button for Source code (tar.gz)
On Fri, Jan 24, 2014 at 4:57 PM, Adam Williamson awill...@redhat.com wrote:
On Fri, 2014-01-24 at 08:13 -0500, Stephen Gallagher wrote:
Interesting... However, if you're working with an actual release
tag, I would think Peter's method would be much better.
It is a good idea to use a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/23/2014 05:49 PM, Adam Williamson wrote:
On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý
msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY
wrote:
Take, for example,
Agreed. But the difference is that using full commits a history rewrite
will always be detected. Using a tag is making it possible for upstream to
bind the same tag to a different commit. And since it's possible, it will
happen.
It's a shame there is no way to block forced updates on github.
On Fri, 2014-01-24 at 08:13 -0500, Stephen Gallagher wrote:
Interesting... However, if you're working with an actual release
tag, I would think Peter's method would be much better.
It is a good idea to use a specific commit as your source, not a
tag, because the tag can be silently
On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com
wrote:
On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote:
Take, for example,
https://github.com/nfs-ganesha/nfs-ganesha/releases, where
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
where there's a button for Source code (tar.gz) pointing at
https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz.
If I click on that link the downloaded
On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote:
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where
there's a button for Source code
(tar.gz) pointing at
https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
Note V2.0.0.tar.gz versus
2014/1/21 Kaleb KEITHLEY kkeit...@redhat.com:
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
where there's a button for Source code (tar.gz) pointing at
https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
I'm using a different scheme (there are few at
On 01/21/2014 12:09 PM, Richard Shaw wrote:
Interesting... However, if you're working with an actual release tag, I
would think Peter's method would be much better.
I agree, but practice has shown that few projects on github are using
release tags.
~tom
==
¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @
On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote:
On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote:
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
where there's a button for Source code
(tar.gz) pointing at
Actually, the GL are pretty clear here: the source should be referenced
using the full commit, nothing else. There is some reasoning why. The tag
should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle difference in
git-archive (which supposedly
On 01/21/2014 12:39 PM, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com
mailto:leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be
referenced using the full commit, nothing else. There is some
reasoning
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be referenced
using the full commit, nothing else. There is some reasoning why. The tag
should got to Version: (as long its 'sane').
Besides that this is the
You could file a issue at the FPC trac, preferably with a proposal for new
GL.
That said, I notice that we use what works for me, despite any GL so
maybe it doesn't matter. Dunno.
--alec
On Tue, Jan 21, 2014 at 6:41 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote:
On 01/21/2014 12:39 PM,
16 matches
Mail list logo
