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
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 (\d+)\.(\d+
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
Jeff King writes:
> On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
>
>> Jeff King 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 wa
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 man
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 abou
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
> Jeff King 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,
Jeff King 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 interested.
I a
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 aut
On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote:
> Ken Moffat 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
>
> ht
Ken Moffat 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
lists the two sites
On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote:
> Vicent Martí 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
> >
Vicent Martí 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 good enou
On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano wrote:
> Stefan Näwe 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]?
>
Stefan Näwe 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 wrong with this:
>
>
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:
https://github.com/gitster/git/arc
Javier Domingo Cansino 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 not the only d
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:
http://google-opensource.blogspot.se/2013/05/a-change-to-google
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
