On 01/28/2014 05:58 PM, Kacper Kornet wrote:
On Mon, Jan 27, 2014 at 10:58:29AM -0800, Jonathan Nieder wrote:
Hi,
Kacper Kornet wrote:
The change in release numbering also breaks down gitolite v2 setups. One
of the gitolite commands, gl-compile-conf, expects the output of git
--version
On Mon, Jan 27, 2014 at 10:58:29AM -0800, Jonathan Nieder wrote:
Hi,
Kacper Kornet wrote:
The change in release numbering also breaks down gitolite v2 setups. One
of the gitolite commands, gl-compile-conf, expects the output of git
--version
to match /git version
On Tue, Jan 21, 2014 at 02:14:22PM -0800, Junio C Hamano wrote:
It has been reported that turning git.rc into git.res does not like
the new 2-dewey-decimal release numbering scheme; packagers of
various distro might find similar issues in their build procedures,
in which case they have about 3
Hi,
Kacper Kornet wrote:
The change in release numbering also breaks down gitolite v2 setups. One
of the gitolite commands, gl-compile-conf, expects the output of git
--version
to match /git version (\d+)\.(\d+)\.(\d+)/.
I have no idea how big problem it is, as I don't know how many
Jeff King p...@peff.net writes:
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the Releases page of git/git. I
imagine there is a
On Mon, Jan 27, 2014 at 02:56:28PM -0800, Junio C Hamano wrote:
# replace this with however you store your oauth token
# if you don't have one, make one here:
# https://github.com/settings/tokens/new
token() {
pass -n github.web.oauth
Hmph, what is this pass thing?
It's a poor
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the Releases page of git/git. I
imagine there is a programmatic way to do so via GitHub's
Jeff King p...@peff.net writes:
Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the Releases page of git/git. I
imagine there is a programmatic way to do so via GitHub's API, but I
don't know offhand. I can look into it if you are
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Cheers
Javier Domingo Cansino
[1] Google Code download service change announcement:
Javier Domingo Cansino javier...@gmail.com writes:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Aside from the obvious we won't be able to use something that is no
longer offered? They are
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Am I missing something or what's wrong with this:
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Am I missing something or what's
On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down
Vicent Martí tan...@gmail.com writes:
Do these consume CPU every time somebody asks for a tarball? That
might be considered wrong depending on the view.
No, our infrastructure caches frequently requested tarballs so they
don't have to be regenerated on the fly.
Thanks. That is certainly
On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote:
Vicent Martí tan...@gmail.com writes:
Do these consume CPU every time somebody asks for a tarball? That
might be considered wrong depending on the view.
No, our infrastructure caches frequently requested tarballs so they
Ken Moffat zarniwh...@ntlworld.com writes:
I note that all of these *are* still available at googlecode for
the moment : https://code.google.com/p/git-core/downloads/list
As I said, Cgc is not the ony download site. The end of
http://git-blame.blogspot.com/p/git-public-repositories.html
On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote:
Ken Moffat zarniwh...@ntlworld.com writes:
I note that all of these *are* still available at googlecode for
the moment : https://code.google.com/p/git-core/downloads/list
As I said, Cgc is not the ony download site. The
On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote:
Two questions: Does regenerating (e.g. if the tarball has dropped
out of the cache) change its sums (md5sum or similar) ? In (beyond)
linuxfromscratch we use md5sums to verify that a tarball has not
changed.
The tarballs we
An early preview release Git v1.9-rc0 is now available for testing
at the usual places. I tagged this late last week, but forgot to
send out the announcement before I left for the weekend, and then I
wasn't well yesterday, but anyway. There still may be a few minor
topics not in this preview but
19 matches
Mail list logo
